[forge-dev] plugin versioning

[Ivan St. Ivanov]

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