r20 - 2015-04-18 - 05:56:09 - HarlanStennYou are here: NTP >  Dev Web > ReleaseIssues > ReleaseVersionNumbers
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Release Version Numbers

Related Topics: EmbeddedVersionStringContent

Post 4.2.8

The current official numbering mechanism is described on the release numbering scheme page.

We're changing to a new release version number scheme for post "4.2.8" releases.

The problem with the current scheme is that people see 4.2.0 and 4.2.6 and think there isn't much difference between them. Consequently, they run old and buggy versions of NTP for a Very Long Time. So the next major stable release after ntp-4.2.8 will be ntp-4.4.x, where x will be the "patch" number (initially 0).

The first development release under this scheme will be ntp-4.3.0 and the subsequent (consequent?) stable release from this work will be ntp-4.4.0.

While the 192nd patch release of the development 4.2.7 was ntp-4.2.7p192, the 192nd patch release in the next cycle would be ntp-4.3.192 in the new scheme.

We're going from PROTOCOL.MAJOR.MINORpPATCH to PROTOCOL.RELEASEpPATCH.

 

Up to/including 4.2.8

In a nutshell, the syntax is Version[Point][Special][ReleaseCandidate] where an example is: 4.2.2p2

The Previous Scheme

Version numbers are of the form ntp-4.2.1.

One way where this is suboptimal is because we only have 2 fields for our use, instead of 3 fields. With the extra field we could more easily identify patch releases.

Alternative Schemes

Alternatives include the following. Please feel free to comment and offer additional solutions.

ntp-4.2.1 (the previous scheme)

  • Pros
    • It's otherwise "normal".

  • Cons
    • The first number is the protocol version, which only offers us major and minor release numbers.

ntp-4.2.1p1 (the current scheme)

  • Pros
    • We have our procol version, then major, minor, and patch releases.

  • Cons
    • This scheme conceals the actual version and misleads users into thinking they don't need to update

ntp-4.2.1-1

  • Pros
    • Easier to read than 4.2.2p1
    • Separates the patch level from the release number more clearly than 4.2.1.1

  • Cons
    • People tend to do a poor job at getting the punctuation right.

ntp-4.2.1.1

  • Pros
    • We have our protocol version, then major, minor, and patch release numbers.

  • Cons
    • Somebody will object because we're using 4 numbers instead of 3; we're being "different".

ntp4-2.1.1

  • Pros
    • We distinguish the program and its protocol version from the major, minor, and patch releases of the package.

  • Cons
    • I tried this with xntp3-* and the vast majority of folks were unable to properly type in the package name (or even the version number of the package name).

This scheme is consistant with current practices in the development world (please feel free to point out cases which disprove my claim). The current scheme conceals the actual version and misleads users into thinking they don't need to update. Eschewing this scheme solely due to typing problems or IRC/mailing-list "noise" is, IMNSHO, misguided. -- SteveKostecke - 2011-02-12

ntp-4.2.1.YYYYMMDD

  • Pros
    • This is nice in that we have a great tie-in with datestamped snapshots.

  • Cons
    • the name is long

Release Candidate Numbering

What should we do about release-candidate numbers?

Harlan wants the releases to collate properly (the ls command).

Currently, release numbers would go from 4.2.0 to 4.2.0-rc1 to 4.2.1.

This is somewhat confusing.

If release candidate tarballs can be removed from the release subdir, we could call the first release candidate for 4.2.1 4.2.1-rc1. While this leaves the tarballs to collate properly, the resulting directories will not collate properly. I'm not sure this is all that significant - once unpacked the resulting directories will collate such that the RC will be after the (newer) production release.

If we get an additional number to use, we can use the existing mechanism and the beta releases of 4.2.1 would be 4.2.0.9x; the first release candidate for 4.2.1 might be 4.2.0.90-rc or 4.2.0.90-rc1.

Additional Release Candidate issues

What about deciding that any beta release is by definition a release candidate? In this case, any .9x release would be a release candidate, and what would hold it up would be blocking bugs or pending "nits"?

Dated snapshot tarball releases

Another new wrinkle is our snapshot tarballs - these tarballs have a datestamp in the filename and some people are asking that the same file have the same name in both places.

Originally we had only the official release area, and no snapshot area.

Can we make better use of the datestamp feature with our release numbers?

Should we forget about the "patch" release number and simply use the datestamp in that field? Doing so would make it difficult to identify alpha or beta/release candidate releases.


Also see the download area layout page.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r20 < r19 < r18 < r17 < r16 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2018 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