NetarchiveSuite
Version Numbering
The netarchive version number is roughly modeled after the Heritrix version numbering, which again is modeled after the linux kernel version numbers.
The version numbers are made up of three parts:
[major].[minor].[patchlevel]
[major] is currently 3, and is only updated on major structural or logical changes
[minor] is updated as progress moves along. It is significant whether [minor] is odd or even. Odd minor versions indicate development versions, and cannot expected to be stable. Even numbers indicate production releases, and should be stable.
[patchlevel] indicates work within a given minor version. On even-numbered versions, only bugfixes are applied as the patch-number increases. On the odd-numbered development version, the patch-number indicates our development progress, and odd version numbers may not reflect a specific version, but rather a state of development.
Examples
3.10.0 indicates the first production release of a 3.10 version of our software. 3.10.1 indicates the version above with an applied bugfix. 3.11.0 will be the development version building on the 3.10 version 3.11.1 indicates some progress has been done on the development
Use of version numbers in development
A coding iteration starts with an odd-numbered version on patch-level zero, e.g. 3.11.0. While developing, the version number will be reporting a build status of UNSTABLE. On codefreeze we will bump this status to CODEFREEZE. On successful releasetest we will either change status to RELEASE, or if it is a final production release we bump the version number to version 3.12.0. We then immediately bump to 3.11.1 UNSTABLE on non-production release, or 3.13.0 for our next development version.
For bugfixing of a production release, we make a branch from the 2.12.0 CVS tag, and immediately bump the version number to 3.12.1. The build status will be UNSTABLE while developing. This version number stays put until release of the bugfix release, the build status will then be RELEASE. Further bugfixing is done on this branch. Don't forget to port them to the development version as well. Note we only apply patches for blocker-bugs. Otherwise bugs are fixed in the next release.
Access to version numbers
The version number is currently available in the code by calling dk.netarkivet.common.Constants.getVersionString(). All applications should log this string on startup.
Apart from that it is mentioned in releasenotes with all releases.