> On Dec 30, 2020, at 2:23 PM, Zack Weinberg <zackw@xxxxxxxxx> wrote: > > On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert <eggert@xxxxxxxxxxx> 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
