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.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

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

The Current Scheme

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

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

The Next Scheme

We're looking to change 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 we're proposing that the next major release after ntp-4.2.* will be ntp4-5.x.y, where x will be the minor release number (initially 0) and y will be the "patch" number (also initially 0).

As a comparison, ntp-4.2.7p192 in the current scheme would be ntp4-2.7.192 in the new scheme.

We're skipping what would otherwise be ntp-4.3.* and ntp-4.4.* to avoid confusion between the "current" and "new" schemes.

The first development release under this scheme will be ntp4-4.9.0 and the subsequent (consequent?) stable release from this work will be ntp4-5.0.0.

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.