Editing EPrints Version Numbering

In EPrints 3 we are following a much more strict set of rules about our version numbers.

An EPrints "series" is all of the releases with the same major and minor code. e.g. 3.0 series, 3.1 series.

A 3.x.0 release will be proceeded by a number of releases coded 3.x.0-alpha-y, 3.x.0-beta-y and 3.x.0-rc-y

The alpha releases may just plain not work. They are provided for people to try out but should never be used for a production system. It will *probably* be possible to upgrade alphas to later versions, but this is not something we will strive to ensure.

The beta releases are a working system, although may have known bugs, and later beta releases may change things around and add new features. If you are planning a new repository it makes sense to work with the latest beta. We don't recommend live services upgrade to a beta (although this may be theoretically possible). 

The rc (release candidates) are intended to be ready to use. It is generally safe to upgrade a live system to a release candidate, but risk-averse repositories may choose to wait until the final 3.x.0 release. Additional rc releases will generally only contain alterations to the default configuration, and bug-fixes. They may gain very minor new features, for example, a new option to EPScript or a new plugin, but only where there is no risk of introducing bugs into the core code. No changes will be made to the database structure.

After a number of sites have run the latest release candidate for a few weeks, without any new bugs being discovered, the last rc release will be released as "3.x.0".

After this we will make later releases of 3.x.1, 3.x.2 with the same policy as the release candidates, that is we'll only add or change things which a minimal chance of introducing bugs. No changes will be made to the database structure. It is possible we will need to introduce new features to a series. This will be done if there is a widespread need for the feature amongst repositories disinclined to jump to the next series. If we add such a feature, that release will go through a beta release first. eg. 3.1.2-beta-1

Changes between series will be much more significant and generally there will be no way to downgrade to an earlier series. A new series will introduce new, and change existing, database structures. It may alter configuration options. It may alter behavior of existing features. Also there may be a set of recommended changes to your repository configuration to take advantage of new features. There may also be compulsary changes, but we will keep these to a minimum.

phew. The long and the short of it is that we want to minimise risk to upgrades from 3.x.0 to 3.x.1 etc. so that people benefit from bugfixes. There are no major risks upgrading between series, but care should be taken to understand the changes.