*Applause!* :)
If anyone else wants to get involved, feel free! I don't think Paul would
mind :) This actually has a few separate components that could be split up
if folks want to collaborate:
1. Plugin installation flow
2. Plugin loading
3. Anything else?
~Lincoln
On Thu, Mar 8, 2012 at 10:00 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
I'll do it :-)
On Mar 8, 2012, at 15:57 , Lincoln Baxter, III wrote:
I completely agree :) never fear! This mechanism was mostly put in place
to prevent horrific crash and burn scenarios where Forge would refuse to
boot (failing with a terrible exception message) when a plugin was API
incompatible.
I'd love to get a full plugin version system up and running. I think
allowing users to select from a list is a good first step. We'll also need
to enhance the loading functionality itself, slightly, in order to support
loading from a version that is not an exact match, but is within the same
minor version. (e.g. 1.n.x, but not 2.n.x)
Any volunteers? I think this would be a great one for someone who's
interested to work on!
~Lincoln
On Thu, Mar 8, 2012 at 9:50 AM, Rodney Russ <rruss(a)redhat.com> wrote:
> I would tend to prefer giving users options over "magic" and would assume
> that there would be a default version selected for the users that don't
> want to think when installing. How would that default be chosen?
>
> -Rodney
>
> ----- "Paul Bakker" <paul.bakker.nl(a)gmail.com> wrote:
>
> > From: "Paul Bakker" <paul.bakker.nl(a)gmail.com>
> > To: "forge-dev List" <forge-dev(a)lists.jboss.org>
> > Sent: Thursday, March 8, 2012 12:50:56 AM GMT -07:00 US/Canada Mountain
> > Subject: [forge-dev] plugin versioning
> >
> > Hi all,
> >
> > Yesterday during the meeting we talked about plugin versioning.
> > Currently Forge checks if there is a tag/branch of the plugin that
> > matches the Forge API version while installing. We discussed if we can
> > test on compatibility of plugins on a CI server.
> >
> > I started thinking about this again and actually think we should
> > re-think the version checking mechanism. Now that Forge is final, the
> > APIs should be stable. They should be stable until we go for a 2.0.0
> > version, which means plugins are not supposed to break on API changes
> > for 1.0.1, 1.1.0 etc. If we do that correctly, it's also not necessary
> > to upgrade plugins each time there is a new release (or be back at
> > building to snapshots which is dangerous). Instead I suggest prompting
> > available versions of plugins during plugin installation (still
> > looking at tags for that), so that a user can choose to use a stable
> > version, some beta or maybe a snapshot. This also gives us the
> > freedom to do minor Forge releases more often without the hazzle of
> > upgrading all plugins once again…
> >
> > Thoughts?
> >
> > Paul
> > _______________________________________________
> > 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
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
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