Release Numbering Scheme Discussion

Related Topics: ReleaseNumberingScheme


Note that if we stick with a 3-part number and move the Protocol from the first number of the version string to the last part of the package name, since we've already had ntp releases starting with 3.x, 4.0.x, 4.1.x, and 4.2.x, we need to be careful about how we number subsequent 3-part releases. Therefore, if we continue with a 3-part release number we're going to start with 4.9.x for development releases and have 5.0.0 be the first -stable release from there.

Given that we don't seem to have a strong need for both Major and Minor releases, we could simply use a 2-part number, Release.Point. With this scheme, there wouldn't be any confusion with any existing numbers, and we could use the following:

Post-4.2.8 possible alterative #2:

Meet the new boss, same as the old boss. Replace PROTO.MAJOR.MINORpPOINT with Proto.Release.Point.


Release TarballSorted ascending
Stable: 4.2.8 ntp-4.2.8.tar.gz
Stable: 4.4.0 ntp-4.4.0.tar.gz
Stable: 4.4.1, beta ntp-4.4.1-1beta.tar.gz
Stable: 4.4.1, RC (after 1beta) ntp-4.4.1-2RC.tar.gz
Stable: 4.4.1, RC(after 2RC) ntp-4.4.1-3RC.tar.gz
Stable: 4.4.1 (after 3RC) ntp-4.4.1.tar.gz
Dev: 4.2.7p400 ntp-dev-4.2.7p400.tar.gz
Dev: 4.5.0 ntp-dev-4.5.0.tar.gz
Dev: 4.3.0 ntp4-dev-4.3.0.tar.gz
Dev: 4.3.100, RC ntp4-dev-4.3.100-RC.tar.gz


Post-4.2.8 possible alterative: ntp4-Release.Point
Release Tarball
Dev: 4-3.0 ntp4-dev-3.0.tar.gz
Dev: 4-3.100, RC ntp4-dev-3.100-RC.tar.gz
Stable: 4-4.0 ntp4-4.0.tar.gz
Stable: 4-4.1, beta ntp4-4.1-beta1.tar.gz
Stable: 4-4.1, RC ntp4-4.1-RC2.tar.gz
Stable: 4-4.1 ntp4-4.1.tar.gz
Dev: 4-5.0 ntp4-dev-5.0.tar.gz


Post-4.2.8 original choice: ntp4-Major.Minor.Point
Release Tarball
Dev: 4-4.9.0 ntp4-dev-4.9.0.tar.gz
Dev: 4-4.9.100, RC ntp4-dev-4.9.100-RC.tar.gz
Stable: 4-5.0.0 ntp4-5.0.0.tar.gz
Stable: 4-5.0.1, beta ntp4-5.0.1-beta1.tar.gz
Stable: 4-5.0.1, RC #1 ntp4-5.0.1-RC2.tar.gz
Stable: 4-5.0.1 ntp4-5.0.1.tar.gz


4.0 thru 4.2.8:

Release Tarball
Stable: 4.2.4p5 ntp-4.2.4p5.tar.gz
Dev: 4.2.3p70, RC ntp-dev-4.2.3p70-RC.tar.gz
Dev: 4.2.3p69 ntp-dev-4.2.3p69.tar.gz
Stable: 4.2.6p5, RC #1 ntp-4.2.6p5-RC1.tar.gz
Stable: 4.2.6p2, beta1 ntp-4.2.6p3-beta1.tar.gz


What I would like to see is to use the major number to indicate the version of the protocol used. The minor release number would be incremented for versions with backward incompatibilities, and the micro release would increment for releases that aggregate bug fixes and backwards compatibile changes.

-- BrianUtterback - 2013-08-03

Brian can you point out any examples of your suggested ReleaseNumberingScheme being used by any other software products?

-- SteveKostecke - 2013-08-03

Brian, what about feature improvements? -- HarlanStenn - 2013-12-30

The problem with the current ReleaseNumberingScheme is that it flies in the face of established convention by using the protocol version where the overwhelming majority of users expect to find the major release number. This causes a vast underestimation of the significance of the delta between versions.

-- SteveKostecke - 2013-12-31

Brian, the top approach above seems to address this, right? Do we really need the granularity offered by Major and Minor release numbers?

-- HarlanStenn - 2014-12-24

This topic: Dev > Main > DocumentationIndex > ReleaseNumberingScheme > ReleaseNumberingSchemeDiscussion
Topic revision: r11 - 2014-12-25 - 03:00:59 - HarlanStenn
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback