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'. > 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. > 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 > 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. Please see the explanation at http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html -David
