Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

 

 

Section
Column
width50%

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.

Column
width50%
Panel
borderColor#dddddd
borderWidth2
borderStylesolid

On this Page

Table of Contents

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. 
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>

  • <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.