[forge-dev] plugin versioning

[Ivan St. Ivanov]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120314/360ba97b/attachment.html