Andrew McIntyre wrote: > Hello derby-dev, > > I've posted a set of 10.1 release candidate jars for testing on my > public html page: > > http://people.apache.org/~fuzzylogic/ > > The link is right at the top. GPG signature and md5 checksum are also > linked there. > > Areas for testing should include upgrade from 10.0, new functionality, > and platform compatibilty. Note that the version of these jars is > 10.1.1.0 - and not beta or alpha. I decided to go ahead and make the > version non-beta in order to facilitate upgrade testing from 10.0 to 10.1.
Marking this jars not alpha/beta defeats the whole purpose of the versioning scheme, which is to ensure that pre-release software does not get used in production environments. A development flag was added to allow testing of upgrade of pre release jars. I'm not sure marking the release as not alpha/beta should be done until the jars have been voted on at derby-dev. In the future we may want to change the versioning code related to alpha/beta to better match the Apache Derby release process, but at the current time the list did vote to accept the existing versioning scheme. As we iron out the release process for future releases, the versioning might need to change, e.g. if there never is a 'beta' phase for any release then there is no point having code for a beta state. This would be a good time to remind people how the release process works, in terms of testing, voting and what a vote means. We have a lot of new developers on the list since the last Derby release. Dan.
