The releases of our software are handled according to this process. They use the numbering policy described below and can go through three different pre-releases. The support policy is also outlined here.

On this Page

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:

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

Examples on version numbers:

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: 

OpenDNSSEC 

Release

Release type

Release date

Supported until

1.0

Standard

Feb 2010

No longer supported

1.1

Standard

May 2010

No longer supported

1.2

Standard

Jan 2011

No longer supported

1.3

LTS

July 2011

1 year after next LTS release

1.4

Standard

April 2013

1 year after next minor/major release

    
SoftHSM

Release

Release type

Release date

Supported until

1.0

Standard

Sept 2009

No longer supported

1.1

Standard

Nov 2009

No longer supported

1.2

Standard

Sept 2010

No longer supported

1.3

LTS

Aug 2011

1 year after next LTS release

    

 

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>