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.
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)
- 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.
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.