> -----Original Message----- > From: David Crossley [mailto:cross...@apache.org] > Sent: Friday, 4 June 2010 12:50 PM > To: dev@forrest.apache.org > Subject: Re: release process for our plugins > > Gav... wrote: > > David Crossley wrote: > > > > > > One very important reason for designing the plugin system > > > the way that we did, was to ensure that each plugin has > > > its own community supporting it. > > > > That doesn't seem to be the case to me at the moment, ... > > That is one reason that i raised this issue again. We knew > in the past that we had not properly followed a separate > release cycle for each plugin. > > > ... when core forrest devs > > want to do a release, we need to ensure all plugins work, at least I > see > > that as the current situation. > > That is different, and we would do that regardless of the > plugins each being released separately. > > 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. 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 ? 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. 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) Thanks Gav... > > -David
