[Opendnssec-develop] RE: Versioning and version support

[Sara Dickinson]

All, 

Following some recent discussions on version support and how we use version numbers I have put this email together to try to summarise some of the points raised. 


Version numbering
----------------------------

We currently use a version numbering system based on the following (and 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.

As a result we often include fixes in 'patch' releases that include extensions (and sometimes changes) to the command utilities and/or log output. This is quite different from the version numbering system used by some other applications which choose to follow an API compatibility based approach e.g. http://semver.org/

Question) Do we as a development team think we should move to an API compatibility based approach for version numbering? 

* We would have to consider what we would define as our 'API (the scheme above assumes that there is a clear, well documented API)'. Command line utilities/database schema/logs/zone content/etc. (This may make much more sense once we have a formal API in future so perhaps we should consider this from 2.x onwards?).
* This would increase the frequency at which our minor and major versions changed (I think)
* We would have to review how we write the roadmap and refer to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content).
* If we decide to recommend this then we should run it past the board (and users) before adopting the new process.
* Alternatively we could retain our current scheme but clarify in the process wiki that <patch> releases contain minor updates and bug fixes (we already do this in the NEWS file).



Version support
------------------------
[The following probably depends on what we plan to do with version numbering so it is here for reference at the moment]

In practice we support only the current minor version.  Should we support the current and previous minor version from 1.4 onwards?

+ better support for users who stay on 1.3
- more overhead (more branches to patch, test and release)
- less incentive for users to upgrade to 1.4

We also used to say the following on the wiki "The oldest supported release will get deprecated 6 months after a new release has been introduced e.g. v1.4 will deprecate v1.1. However a released version will be maintained at a minimum of 12 months."




Comments welcomed!

Sara.