[forge-dev] plugin versioning

[Lincoln Baxter, III]

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