[forge-dev] plugin versioning

[Lincoln Baxter, III]

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