Version Numbering Policy

There are two different numbering schemes in use, one scheme for binaries and another for libraries.

Numbering of binaries

For earlier releases a component based numbering scheme was used (listed at the bottom of the page for reference). From 1.4.0 and 1.3.14 onwards OpenDNSSEC will switch to using an API based versioning scheme as described here: 

Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>. We base our scheme on that described by http://semver.org/ which summarises to:

•  <name> - The name of the software, e.g. opendnssec or softhsm.
•  <major> - Backwards incompatible changes must increase the major version.
•  <minor> - New, backwards compatible functionality, deprecated functionality (while maintaining backwards compatibility), or substantial new functionality within private code.
•  <patch> - Backwards compatible bug fixes or new, backwards compatible command line utility options (that will not change the behaviour for existing options).

Pre-releases have one of the following suffixes appended to the above. They are described more in detail in a section below.

• aN - alpha release (very volatile development releases)
• bN - beta release (no new features in beta releases)
• rcN - release candidate

Examples on version numbers:

• 1.0.0b1 is the 1st beta for 1.0.0
• 1.0.0rc1 is the 1st release candidate for 1.0.0
• 1.0.0 is the first real (production) release
• 1.0.1 is a fix for 1.0.0

Numbering of libraries

The shared libraries are numbered according to the libtool's versioning system:  http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning

Pre-releases

Before a release is actually done, it can be distributed as test versions to the general public. Moving between alpha, beta, and release candidate depending on the stability of the software. There is no requirement that all of these stages must be passed in order to do a release, but it is recommend to do pre-releases when major or minor changes are done. 

Alpha release 

The alpha release is used to get feedback from the user community on new features that have been developed. However, the code base is still under development and may suffer from stability issues.

Beta release 

The software can be released as a beta once all features have been implemented. No new features can be added after the first beta release. This is to ensure that focus can be on testing the current set of features.

Release candidate 

The code is considered to be stable enough for an actual release, but the developer team wants to gather any remaining feedback from e.g. package maintainers or external testers. The final release can be done where there is no more feedback coming in.

Maintenance of old releases

From 1.3 we are adopting a split between Long Term Support (LTS) releases and Standard Releases somewhat along the lines of the Ubuntu model. Specifically: 

• Long Term Support Releases
  Long Term Support releases will be supported until one year after the following Long Term Support release. 
  
  • 1.3 is declared as a the first Long Term Support Release
  • The next Long Term Support release will be 2.0 at the earliest
• Standard releases
  Minor releases will be maintained (i.e. patch releases will be made available) for a fixed period after the release of the next minor release (or next major release if there is no further minor release on that branch).  As an example, 1.4 will be maintained for 1 year after the next (non-patch) release, which could be 1.5 or 2.0. The specific support period for a standard release will be announced when the production release of that version is made. 

Versioning scheme used for early versions of OpenDNSSEC (pre 1.3.14)

Numbering of binaries

Releases were numbered using the following scheme: <name>-<major>.<minor>.<patch>

• <name> - The name of the software, e.g. opendnssec or softhsm.
• <major> - Indicate changes in the overall system design.
• <minor> - Indicate changes in the components.
• <patch> - Indicate bug fixes.