> -----Original Message----- > From: David Crossley [mailto:cross...@apache.org] > Sent: Monday, 7 June 2010 10:28 AM > To: dev@forrest.apache.org > Subject: Re: release process for our plugins > > Gav... wrote: > > David Crossley wrote: > > > > > > It should be easy to whip around each plugin and > > > do a proper release of each. > > > > > > That also means that each plugin has a specific marked > > > version, rather than just a continual work-in-progress. > > > > OK, when updating documentation for a plugin, all we need to is do > > an 'ant deploy' on the plugin. > > No. If only docs have changed then '... ant deploy-docs'.
ah ok great, I missed that option. > > > 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? 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. > > > What happens to the older versions of the plugins ? The plugins > system seems > > a bit > > broken currently, doesn't matter what forrest version you choose when > > looking > > at the plugins page, it shows the same plugin versions in all version > tabs. > > The system isn't broken. It is just that people maintaining > the plugins have not handled them properly. > > For example, the pdf plugin was updated and requires v0.9 but > has not had its "forrestVersion" incremented. Nor was it > deployed for 0.8 before making changes that require 0.9 version. > See FOR-1187. > > Similarly with the Dispatcher. It still says forrestVersion 0.8 Ok, but still, I'm confused as to why 0.8 version plugins, i.e. most of them, are appearing in the 0.7 and 0.9 versions of the plugins page. That's what I see as broken. > > > 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. 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. (?) Any more tweaks I make to those docs I'll just do a ant deploy-docs on them. Gav... > > -David
