> On Dec 30, 2020, at 2:23 PM, Zack Weinberg <za...@panix.com> wrote:
>
> On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert <egg...@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
