[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf
Subject:    Re: Autoconf version number after 2.70
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2020-12-30 22:47:56
Message-ID: 223141AE-1117-451B-8595-0ED3E26B1B78 () dwheeler ! com
[Download RAW message or body]



> 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


[prev in list] [next in list] [prev in thread] [next in thread]