Thanks for thinking out aloud. That certainly helps. > User Testing > ------------ > > Bleeding edge users can use the latest *released* development version by > omitting a version number. Note they do *not* use the trunk version > unless Forrest is able to find the trunk source locally, in which case > it will use that version. > > To move a plugin into the user testing phase we will need to deploy the > plugin as a dev version. > > Release > ------- > > After a suitable period of user testing we release the plugin, making it > available as a new version number. The "careful" users can then choose > to upgrade their version numbers or not.
So when we release a plugin then we increment its version number in the forrest.properties of the template "seed" sites. At release time, they will be declaring specific release numbers, and users take it from there. Is that the idea? Sounds good. How do people know when new versions of the plugins are available? At least we would add to top-level status.xml so that it gets listed on the changes.html page. Do we make an actual announcement too? http://forrest.apache.org/guidelines.html#actions The project is supposed to vote on a "Product release". That action was written with the traditional "Release" in mind (i.e. 0.7 then 0.8). I wonder if it should apply to our plugins too. -David > Life Cycle Summary > ================== > > I propose that each plugin will have up to three versions at any one time: > > - dev version (src code local to installation) > - testing version (deployed, but unversioned copy) > - released version(s) (deployed and versioned copy) > > How? > ==== > > I *think* all that needs to be done is to enable plugins to be used > in-place [1] and document this. > > Any thoughts/comments? > > Ross > > [1] http://issues.apache.org/jira/browse/FOR-388
