...
For example, we might have:
- v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects // a "wicket/jdo release" - eg tested and released by Dan
- v0.4.0 core + objectstore-nosql + viewer-scimpi // a "scimpi/nosql release" - eg tested and released by Rob
- v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd // a "dev release" - eg tested and released by Rob
- v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects // another "wicket/jdo release"
- v0.7.0 core + objectstore-sql + viewer-html // a "html/sql release" - eg tested and released by Kevin
- v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects // another "wicket/jdo release"
Whenever a release goes out, we would update the site to indicate the most recent version of the components.
Now, when I say "release", what I actually mean here is the deployment of binary artifacts up to the Maven central repo. This, after all, is what most users/would-be users in the community would use and consider a release. However, Apache's own formal definition of "release" is actually the source code release ... this is what the VOTE mechanism is for. I don't see this changing... the vote basically says that the software complies with all the legal license stuff etc. The whole codebase is tagged with that release number, and the generated src.zip is a zip of this release.
...