bug#68274: automake 1.16j nonnumerical version confuses scripts

[Sam James]

"Zack Weinberg" <zack@owlfolio.org> writes:

> 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.
>

I was planning on finally filing a bug for this because I couldn't really
package the latest automake pre-release given it totally breaks our
sorting (and afaik sorting in every other PM too).

We're used to .9x and it works fine for us.

thanks,
sam