The default could be the same as our current "magic" ;-) So the default is either the tag/branch that matches the current API version, and snapshot otherwise. Or instead, always default the latest tag, never snapshot. Paul On Mar 8, 2012, at 15:50 , Rodney Russ wrote:

Regarding some of the things that were discussed in yesterday's meeting, like notifying plugin authors of a new version. I think this could still be a good idea, but we should also reduce the need for such a mechanism with the above. ~Lincoln On Thu, Mar 8, 2012 at 9:57 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com > 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> >> 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>> >> > From: "Paul Bakker" <paul.bakker.nl(a)gmail.com&gt; >> > To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; >> > 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" > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

*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&gt;wrote: -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"