bug#68274: automake 1.16j nonnumerical version confuses scripts
On 21 Jan 2024 14:42, Karl Berry wrote: > I changed the pretest version to 1.16.90. Closing. thx bud. i appreciates you. -mike signature.asc Description: PGP signature
bug#68274: automake 1.16j nonnumerical version confuses scripts
I changed the pretest version to 1.16.90. Closing.
bug#68274: automake 1.16j nonnumerical version confuses scripts
"Zack Weinberg" 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
bug#68274: automake 1.16j nonnumerical version confuses scripts
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
bug#68274: automake 1.16j nonnumerical version confuses scripts
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. i cut more inline responses to avoid further bikeshedding on the topic. we can agree to disagree. -mike signature.asc Description: PGP signature
bug#68274: automake 1.16j nonnumerical version confuses scripts
there is nothing requiring or restricting the current version behavior other than "it's always been this way". True. but that doesn't mean it's better. No way to know what release or test scripts might be relying on the current convention. Changing for the sake of change doesn't seem good. there's no reason we couldn't use more modern convention here like -rc#. I don't much like it, since "rc" always makes me think first of rc files. It also wouldn't fix the problem in jami (still not numeric). 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.
bug#68274: automake 1.16j nonnumerical version confuses scripts
On 06 Jan 2024 15:37, Karl Berry wrote: > Automake and other packages have used letters for pretests for decades, true ... > and it's not plausible to change now. eh ? there is nothing requiring or restricting the current version behavior other than "it's always been this way". but that doesn't mean it's better. there's no reason we couldn't use more modern convention here like -rc#. appending a letter at the end to indicate a *pre*release is extremely uncommon nowadays. > Also, I have the impression that other packages use random git hexids in > their pretest releases, which aren't numeric either. -k some do, but they use separators which makes it easier to split+compare. if they smashed it together, it'd be impossible to determine where the version stopped and where the git sha started. e.g. 1.2.3-gab989de -mike signature.asc Description: PGP signature
bug#68274: automake 1.16j nonnumerical version confuses scripts
Carl - sorry, you'll need to adjust your script. Automake and other packages have used letters for pretests for decades, and it's not plausible to change now. Also, I have the impression that other packages use random git hexids in their pretest releases, which aren't numeric either. -k
bug#68274: automake 1.16j nonnumerical version confuses scripts
Building a package (happens to be "jami") , which runs a script it its build process that checks for automake expr: non-integer argument automake (GNU automake) 1.16j Fatal error: automake 1.7 or higher is required. Please set $AUTOMAKE to point to a newer automake, or upgrade. Problem is the script expects numerical version, thus gets confused. Next version, make it something like "automake 1.16.9" or something.
