[Opendnssec-develop] RE: Versioning scheme

[Sara Dickinson]

Hi All, 

The development team had a discussion last year about the versioning scheme used for OpenDNSSEC and the general feeling was that it would make sense to switch from the current component based scheme to an API compatibility based approach. The upcoming release of 1.4 would be a suitable time to change the versioning scheme so I wanted to run this past the board to see if anyone has strong feelings either way before we go ahead with this. The details of the current and proposed scheme are below.

We would obviously need to communicate this change to the users effectively. One impact of the change would probably be to increase the frequency at which the minor versions increased.  We might also have to review how the roadmap refers to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content) and review what maintenance we provide on older releases too.

Regards

Sara.


Current scheme
----------------------------

The current version numbering system based on the following (and also direction from the board about what functionality they would like to see in what release): 

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

In practice 'patch' releases often include updates that extend (and sometimes change) functionality, command utilities and/or log output. 


Proposed scheme
-----------------------------

Something along the lines of  e.g. 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, or substantial new functionality within private code.
	• <patch> - Only backwards compatible bug fixes.

This does assume a clearly defined API, so there is an argument for postponing any change until there is a unified control interface for ODS but for 1.4 this could be based on the command utilities and database schema. Note that it also doesn't explicitly exclude bumping the major version for major functional changes in private code.