Gav... wrote: > David Crossley wrote: > > Gav... wrote: > > > > > > When code has been changed on a plugin since the last release, are we > > using > > > the > > > policy of 'lets upgrade the forrest version required as well as the > > plugin > > > version number' - that would make it easier all round. If that is ok, > > then I > > > can > > > just go round all plugins that have had any code changes since April > > 2007 > > > and bump > > > their forrest version numbers to 0.9 ? > > > > No. We are not using that policy. > > > > The "forrestVersion" only gets incremented if there are > > changes that "require" the current version of Forrest. > > > > To do what you are suggesting would mean that users of the > > released versions of Forrest would not get any plugin updates. > > Ok, but the plugins when rebuilt will be done so with Java 1.5 , how > will that affect things?
Ah good point. We should have done a deploy of all plugins that had Java code (only some do) before doing that change. To answer, i don't know what effect it will have. > It's been so long since some were updated that I guess they would need > testing on 0.8 release before deciding if they are still compatible or > not. This is part of our past problems. We don't deploy those plugins often enough and don't pay sufficent attention to their version numbers. Hmmm, i don't know what to do. > > > Obviously any 'plugin releases' between forrest versions can just > > have their > > > 'plugin > > > version' bumped - and for any of these we intend to start voting on? > > (After > > > this > > > next Forrest release if I'm interpreting correctly) > > > > Again only if it "requires" v0.9 functionality. > > huh, Im talking 'plugin version' such as 0.1, 0.2, 0.3 not the > 'forrest version' > > But I get it now I think, any total code changes that warrant a new > plugin version number, such as any release would. Minor code changes > whould stay at the same version number until there are sufficient to > warrant a bump in number (i.e release) - And, if any of those code > changes introduce 0.9 specific functionality, then we bump the 'forrest > version' also. Therefore it is assumed the 'forrest version' number is > the _minimum_ version we are saying it _will_ work on. > > > Please see the explanation at > > http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html > > Oh, how I've read that a million times these last couple of days. Yeah, i understand. There are also some past dev discussions where Ross explained it. Also there are some JIRA tickets. > I have just updated the POD plugin - it had code changes from 2 years > ago, + doc changes and references dispatcher related documentation > examples that are or will be 0.9 specific, so I hope I was right in > bumping both the 'forrest version' and 'plugin version' in this case. (?) Bringing my comment over from that edit to try to keep the discussion together. http://thread.gmane.org/gmane.text.xml.forrest.cvs/9889/focus=27975 > > Sure it may have been updated, but if its own functionality > did not substantially change then leave its ""plugin-version" as-is. > > Did it require new "0.9" functionalty, If so then also > increment its "forrest.version". > > By the way would need to also happen in the Plugins descriptor file > e.g. plugins/plugins.xml etc.
