[ntp:hackers] hackers] NTP software numbering

Magnus Danielson magnus at rubidium.dyndns.org
Thu Dec 25 12:50:06 UTC 2014


Harlan,

On 12/25/2014 05:16 AM, Harlan Stenn wrote:
> Magnus Danielson writes:
>> Hal,
>>
>> On 12/25/2014 12:08 AM, Hal Murray wrote:
>>>
>>> stenn at ntp.org said:
>>>> We're talking about changing from:
>>>>    ntpd 4.2.8p1-beta1 at 1.3268-o Wed Dec 24 21:02:52 UTC 2014 (2)
>>>> to:
>>>>    ntpd 4 v2.8.1-beta1 at 1.3268-o Wed Dec 24 21:02:52 UTC 2014 (2)
>>>
>>> Does anybody but a geek care what the protocol version is?
>>>
>>> My vote would be to drop the protocol from the package/tar name.
>>> That leaves you with major/minor/whatever to use as is convenient.
>>> There is a tradition of distros sometimes adding their own patches so
>>> whatever you do should leave room for that.
>>>
>>> I don't care much about the details of the version string that
>>> programs print out.
>>>
>>> If/when we ever change the protocol in a way that matters we can
>>> revisit the issue.
>>
>> Does not fly very well.
>>
>> When NTPv5 protocol comes along, there will be a ntp4 v2.<something>
>> which will be replaced by ntp5 v1.<something>. Both will have a ntpd
>> in it.
>>
>> Some packaging maintainers may want to maintain ntp4 in parallel with
>> ntp5 until ntp5 has settled in peoples mind. Both do however provide
>> the basic service of ntp.
>
> When we have an NTP5 ntpd available, it *must* interoperate with v4
> clients and servers.  So I'm not sure this case is any different than it
> is trying to install both 4.2.6 and 4.2.8 at the same time.
>
> That can be done today using "modules" or "stow".

What packages maintainer might want to do is to provide the ntp4 and 
ntp5 in parallel, something you don't do with 4.2.6 and 4.2.8. This is 
commonly used when you have pre-stable packaging that you don't want to 
directly replace the main thread, but make it available for those that 
want to play. Depending on the conservatism of the users, they stick to 
the older for a long time.

The interoperability is thus another issue.

>> The NTPv5 will likely contain several elements of properties which is
>> unlike todays NTPv4, so I suspect that it won't be a direct drop-in
>> replacement, which is why it's also a new majorn-release.
>
> Sure, and we've had different major releases before, and we'll have more
> in the future.  We're about to start a major release overhaul for the
> NTP4 codebase, for example.  So if the next -dev stuff becomes
> ntp-4.3.X, the followon -stable release will be ntp-4.4.x.
>
> We'll keep bumping  the release number (the 2nd field) as long as we
> need.
>
> Eventually, we'll start working on ntp-4.999.x or ntp-5.1.x (as the
> development release before ntp-5.0.x or ntp-5.2.x, depending on what we
> want the first -stable release to be called).

Indeed.

>> NTPv5 is still an unknown animal, but we might be toying with it
>> within a few years or so, who knows, and then this will come back and
>> haunt us.
>
> Yes, work on NTPv5 will be starting soon enough, perhaps within a year.

There is already ideas being discussed, things that break the current 
set of RFCs and code.

>> Besides, moving from ntp-4.2.8p0 to ntp-2.8.1 is not working well
>> either, number revision-wise, while moving to ntp-4.2.8p0 to ntp4-2.8.1
>> works, but is indeed quirky, but sufficiently good in my mind.
>
> You're talking about tarball numbers, so we'd be moving from
> ntp-4.2.8.tar.gz to ntp4-2.8.1.  And nobody is talking about doing that
> - the numbering scheme for 4.2.8 will be th same as it we have ben
> doing.  We wouldn't shift to the new scheme until the ntp-dev release
> that comes after 4.2.8, which would result in a new numbering scheme for
> -stable.
>

Which only means my example was badly chosen, not the point it 
illustrated. Remember that it isn't only tar-ball numbers, but also the 
resulting package numbering as they will be wrapped into packages, thats 
how the majority of the users get it anyway.

Cheers,
Magnus


More information about the hackers mailing list