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(a)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(a)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(a)gmail.com>
> wrote:
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev