[forge-dev] plugin versioning

Lincoln Baxter, III lincolnbaxter at gmail.com
Wed Mar 14 16:57:14 EDT 2012


Strange! Everyone should have access! I hate JIRA sometimes... try logging
out then back in again?

~Lincoln

On Wed, Mar 14, 2012 at 11:49 AM, Ivan St. Ivanov
<ivan.st.ivanov at gmail.com>wrote:

> I'm afraid I don't have permissions for that
>
>
> On Wed, Mar 14, 2012 at 5:17 PM, Lincoln Baxter, III <
> lincolnbaxter at gmail.com> wrote:
>
>> Yes, let's create a JIRA for this! Thanks, Ivan!
>>
>>
>> On Tue, Mar 13, 2012 at 6:38 PM, Ivan St. Ivanov <
>> ivan.st.ivanov at gmail.com> wrote:
>>
>>> Hi Lincoln,
>>>
>>> Yes, that's the source for email addresses! We were discussing about
>>> notifying authors just of the so called "blessed" plugins, so maybe the
>>> central repository yaml is the right collection of those plugins.
>>>
>>> Should I create the JIRA?
>>>
>>> Cheers,
>>> Ivan
>>>
>>> P.S. Tomorrow I am skipping the forge meeting. I have another
>>> appointment at work
>>>
>>> On Mon, Mar 12, 2012 at 3:39 PM, Lincoln Baxter, III <
>>> lincolnbaxter at gmail.com> wrote:
>>>
>>>> Hey Ivan,
>>>>
>>>> I agree with your summary.
>>>>
>>>> I think that we should update Forge's version resolution during
>>>> installation to be a little more lenient (I believe Paul has volunteered
>>>> for this?)
>>>>
>>>>  But it does make sense to notify authors of a new release. Actually,
>>>> we already have a great solution for keeping track of who needs to be
>>>> notified! The central plugin repository itself has the information we need!
>>>> (Or it should, in order to be listed, contain a valid email address of the
>>>> plugin author.)
>>>>
>>>> What do you think?
>>>> ~Lincoln
>>>>
>>>>
>>>> On Sun, Mar 11, 2012 at 2:18 PM, Ivan St. Ivanov <
>>>> ivan.st.ivanov at gmail.com> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> On the meeting on Wednesday I took the action item to write a JIRA
>>>>> issue for creating automated routine that checks a set of plugins for their
>>>>> versions and emails their authors if that version is different than that of
>>>>> Forge.
>>>>>
>>>>> I'd like to summarize after looking at this discussion. I assume that
>>>>> we should first change the way Forge resolves the version to install. I
>>>>> agree that we should allow installing plugins which major version
>>>>> (expressed in tag or branch) is the same as that of Forge. So, if Forge is
>>>>> 1.2.3, then all 1.x.y are allowed (1.1.5, 1.2.3, even 1.3.0), but not
>>>>> 2.0.1. I also agree that there should be an option for the user to decide
>>>>> which of the allowed versions to apply with the highest as default (or the
>>>>> "closest" to Forge's version?).
>>>>>
>>>>> As for my action item, I think I should still create it (it's still
>>>>> valid). Do you think that something like this is fine: "Create a routine,
>>>>> executed by the build server, that checks a predefined set of Forge plugins
>>>>> for version consistency with Forge core. In order to satisfy this
>>>>> check, for each major version of the core there should be at least one
>>>>> plugin branch or tag that specifies the same major version. If the check
>>>>> fails, the plugin author should receive an email asking them to fix the
>>>>> inconcistency."
>>>>>
>>>>> As for Dan's and Max's proposals, I think we should consider them only
>>>>> if we decide that we need more complex version rules.
>>>>>
>>>>> Regards,
>>>>> Ivan
>>>>>
>>>>> On Fri, Mar 9, 2012 at 2:44 AM, Max Rydahl Andersen <
>>>>> manderse at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>> if you are going that route - checkout OSGI versioning rules/syntax.
>>>>>>
>>>>>> That has good defaults and deterministic version ranges
>>>>>>
>>>>>> /max
>>>>>>
>>>>>> On Mar 8, 2012, at 10:55 PM, Dan Allen wrote:
>>>>>>
>>>>>> > Although it has a slightly different focus, I advise reading up on
>>>>>> Bundler, the Ruby library versioning tool created by Yehuda Katz to bring
>>>>>> sanity to rails plugins.
>>>>>> >
>>>>>> > It has an interesting version symbol to indicate upgrading along a
>>>>>> major version:
>>>>>> >
>>>>>> > ~> 1.1.0
>>>>>> >
>>>>>> > That will allow 1.2.0, but not 2.0.0.
>>>>>> >
>>>>>> > Bundler also has the idea of version locking across the transitive
>>>>>> closure.
>>>>>> >
>>>>>> > --
>>>>>> > Sent from my CyanogenMod-powered
>>>>>> > Android device, an open platform for
>>>>>> > carriers, developers and consumers.
>>>>>> >
>>>>>> > On Mar 8, 2012 10:21 AM, "Lincoln Baxter, III" <
>>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>> > _______________________________________________
>>>>>> > forge-dev mailing list
>>>>>> > forge-dev at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lincoln Baxter, III
>>>> http://ocpsoft.com
>>>> http://scrumshark.com
>>>> "Keep it Simple"
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120314/69ea25f1/attachment.html 


More information about the forge-dev mailing list