[ntp:hackers] NTP software numbering

Harlan Stenn stenn at nwtime.org
Sun Dec 21 11:54:05 UTC 2014


Thanks for weighing in, Terje.

On 12/21/14 3:13 AM, Terje Mathisen wrote:
> Harlan Stenn wrote:
>> Thanks, Greg!
> 
> I think we should "bite the bullet" and change the naming to ntp4-*, it
> would definitely make it easier for me here to persuade people that
> 4.2.4 is way outdated. :-(

That means that when we start on v5, the "package name" will be "ntp5",
with whatever version numbers we choose for that one.

I can see these things going either way - there are significant plusses
and minuses with each approach.

I can hold off on rolling a -dev release for a while, as I'd like to
resolve this before the next -dev roll.

One thing I notice is that people want to call the software "4.2.6" or
"4.2.8".  If we switch as originally planned, the next -dev release will
be ntp4-4.9.0.  Yes, if folks call that 4.9.0 we'll be able to
disambiguate it.  And when it goes to -stable it will be ntp4-5.0.0, and
they'll call it 5.0.0.

This will be fun, as eventually, somewhere along that timeframe we
should have the first release of ntp5 out there, and that first stable
release will likely be called ntp5-0.0.0 (or perhaps ntp5-2.0.0)

There will also likely be an NTPv6 sometime.

It would be great if this numbering system worked then, too.

Having the protocol number "first" in the version number sucks because
it downplays the significance of the updates.

That's mostly why I'm thinking of changing from PROTO.MAJOR.MINORpPOINT
to PROTO-MAJOR.MINOR.POINT, and as of a day or so ago, I'd also be
mostly happy with either ntp-PROTO.RELEASE.POINT or ntpPROTO-RELEASE.POINT.

The downsides that I see to this are 1) that stable releases will go
thru just a few POINT updates, but dev releases can ago thru a lot of
them,and 2) how difficult will it be when trying to convince somebody to
upgrade from 4.4.x to 4.6.x (stable releases would still have even numbers)?

Will that be OK?

As far as beta and release candidates go, for -stable we would append
-beta followed by an increasing number (for subsequent updates), and -RC
followed by an increasing number (for subsequent updates).  This keeps
the point release churn for -stable releases to a minimum.

For -dev releases, we have traditionally kept bumping the POINT value,
and if it's a release candidate we append -RC to the number.

This should still be OK for whatever we come up with, but we do need to
keep it in mind.

H
--
> Terje
>>> On Dec 20, 2014, at 7:20 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>>>
>>>
>>> Harlan Stenn <stenn at nwtime.org> writes:
>>>
>>>> We decided to change the version numbering system after 4.2.8 was
>>>> released.
>>>>
>>>> Most recently, we've used ntp-PROTO.MAJOR.MINORpPOINT .
>>> So you can call it proto, but people who see version numbers see
>>> W.X.YpZ.
>>>
>>>> This sucks because people don't see much of a change between 4.2.6 and
>>>> 4.2.8.
>>> Also because it uses a p instead of a dot, making it less likely to
>>> trivially work with all packaging systems without hand coding.
>>>
>>> (This may be ok, but I've had to do a lot of hand coding to work around
>>> packages that think they're special and should have odd version
>>> numbers.)
>>>
>>>> So we thought about going back to ntpPROTO-MAJOE.MINOR.POINT.
>>>>
>>>> This means that the next -stable release will be ntp4-5.0, and the next
>>>> -dev release for ntp4-5.0 will be ntp4-4.9.0.
>>>>
>>>> This kinda sucks too, because folks don't like to mix - and . in their
>>>> version numbers.
>>> It's worse that that.  "ntp4-4.9.0" is version 4.9.0 of the "ntp4"
>>> package.   You can declare it otherwise, but that's how packaging
>>> systems see it. Basically, the rule is that the stuff before the first -
>>> is the package name and the stuff after is the version.
>>>
>>> There are two consumers of version numbers.  One is people, and the
>>> other is packaging systems.   Packaging systems have to interpret
>>> version numbers from tons of packages and be able to do comparisons to
>>> determine what's newer.
>>>
>>> Even worse, going from ntp-4.x.y to ntp4-5.0 is viewed as a change in
>>> the package name.
>>>
>>>> Before we get too far down the road, I'm thinking about something
>>>> halfway between these two, as we don't seem to really go thru many
>>>> major
>>>> and minor releases in any given protocol lifetime.
>>>>
>>>> So I'm thinking about having the next -stable release of NTP after
>>>> ntp-4.2.8 be ntp-4.4.0, so the first -dev release on the way to
>>>> ntp-4.4.0 would be ntp-4.3.0.  No more XXXpNN, the bottom number would
>>>> be the point release.
>>>>
>>>> So the numbering would be:
>>>>
>>>> ntp-PROTO.RELEASE.POINT
>>>>
>>>> and we'd continue having even number releases be -stable, and odd
>>>> number
>>>> releases be -dev.
>>> That's much saner.  I would say that in
>>>
>>>   ntp-4.3.1 (to pick an example with different numbers)
>>>
>>> that 4 is the major version, 3 minor and 1 point/patch.   That's just
>>> how it is to someone reading version numbers who hasn't gotten the memo
>>> about why ntp is odd.  Or rather there are just 3 numbers and no
>>> particular semantics should be assumed.
>>>
>>> But that's ok, because the only real operation packaging systems have to
>>> do is "is this version greater than this other version", and to expect
>>> ntp-x.y.z.tar.gz to unpack into a directory ntp-x.y.z.
>>>
>>> And, there's no reason version components have to be single digits.
>>> quagga is at 0.99.23.1.  THere's some goofiness about the mythical 1.0,
>>> but the big version number has not caused complaints or trouble.
>>>
>>> The second proposal also avoids the package name change.
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> http://lists.ntp.org/listinfo/hackers
>>
> 
> 

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!



More information about the hackers mailing list