bug#68274: automake 1.16j nonnumerical version confuses scripts

[Zack Weinberg]

On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
> On 13 Jan 2024 15:58, Karl Berry wrote:
>> Another alternative: when this came up 30-odd years ago, rms changed the
>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>> that would at least have the benefit of following a recommendation, and
>> as a side effect, would also fix jami's assumption (poor practice though
>> it is, IMHO).
>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>> 
>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>> (rough guess with some grep counting) the .90 convention is by far the
>> most common approach (a couple thousand), followed by the suffix letter
>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>> are both trailing the field. Other random conventions also present.
>> 
>> It all feels like bikeshedding to me, so my inclination is to do
>> nothing.  If we do change, I think we should use .90.  --best, karl.
>
> using .90 is certainly better than single-letters.  if you're fine with
> it, then let's switch.

For what it's worth, I had planned to switch Autoconf, starting with the
next release, to use *some* version numbering scheme for beta releases
that sorts correctly according to things like strverscmp() and
dpkg --compare-versions.  The "append a letter to the version number
intended for the final release" convention makes these algorithms sort
the betas *after* the release, which is backwards.

My plan *was* to append letters to the version number for the *previous*
release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
which I think is what Automake is doing now) but I like .9x version numbers
better because it's more common (as you observed) and therefore more likely
to be understood at sight.  I'd actually forgotten that .9x versions were
an official GNU recommendation.

zw