Re: Autoconf version number after 2.70

[David A. Wheeler]

> On Dec 30, 2020, at 2:23 PM, Zack Weinberg <zackw@panix.com> wrote:
> 
> On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>> 
>> Given the changes being discussed (which seem good ones), I suggest
>> calling the next Autoconf release 2.71 not 2.70.1, as the latter
>> would use a new-to-Autoconf numbering convention that might be more
>> trouble than it's worth.
>> 
>> There was little difference (and only a month) between Autoconf 2.66
>> and 2.67, so there's precedent for putting only a few changes into
>> Autoconf 2.71 and publishing it relatively quickly.
> 
> I’ve thought about this suggestion for several days now.
> 
> Are you saying that a version number like “2.70.1”, with three
> components, might be “more trouble than it’s worth” for *technical*
> reasons, such as programs that assume Autoconf’s version numbers
> always have only two components?  If so, can you articulate how much
> of a risk you think we’d be taking by using a three-component version
> number, and why?

I recommend switching *to* at least 3-number version numbering, as originally 
proposed.

It’s often unclear if “2.70” is before “2.8”. When there are 3 numbers, the 
version number
Is unambiguously *not* a real number & the confusion mostly disappears. 

Also, most programs of autoconf’s size have switched to semantic versioning 
(SemVer),
where 3 numbers are required. Trying to retain the old version numbering 
convention
Is a hindrance, not a help.

--- David A. Wheeler