David Crossley wrote:
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.
That's the idea, yes.
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?
I would say, yes. People can also subscribe to the changes.rss feed in
the plugin docs.
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.
Yes, I would say that is sensible. We have already seen how releasing a
plugin causes problems. Requiring vote will ensure a little more
oversight. However, since many people will not be using the plugin we
should make it a simple consensus vote.
Ross
