Re: [PATCH] add patchlevel to --version output

[Wesley Schwengle <wesleys@xxxxxxxxxxxxxxx>]

On 5/31/26 03:21, dana wrote:

> On Sun 31 May 2026, at 00:13, Wesley Schwengle wrote:
> > There is one thing I think we shouldn't do, and that is using .999
> > in test releases, perhaps a better way is using ~, like Debian to
> > indicate release candidates, eg 5.9.0~rc4 or 5.9.0~test1. is-at-
> > least may need some additional logic to deal with this, but I
> > think it is cleaner that 5.9.999.3-test.
>
> i wish you'd said so before i changed it...

Sorry, I wasn't really active on the maillinglist in the past few months
(or in the past year if honest).

> i don't really care for the 999 thing either, it was just an easy
> fix that didn't require changing anything else about the current
> system
>
> but i also don't like using the `git describe` string as-is because
> it makes it too hard to tell how certain builds compare,
> particularly in the period between a major release and the next test
> release
>
> i would be open to a scheme like dpkg's where e.g. 5.10 >
> 5.10~test4. but you can't use '~' in git tags. and using '-' like
> semver would break too many assumptions for is-at-least

I think during our irc-discussion on the topic the preference for 
odd/even for releases vs development became a strong preference. At 
least for me it did.

But even in those cases, a tagged pre-release is.. I'm not sure. tag vs 
release might be automated? ./zsh-release --version 5.9.2 --rc 2 
becomes 5.9.2~2 and tags it at 5.9.2-rc2?

Git sorts refname correctly:

git tag --sort v:refname -i

In git's own repo:

$ git tag --sort v:refname -i --no-column | tail -10
v2.52.0-rc1
v2.52.0-rc2
v2.53.0
v2.53.0-rc0
v2.53.0-rc1
v2.53.0-rc2
v2.54.0
v2.54.0-rc0
v2.54.0-rc1
v2.54.0-rc2


Cheers,
Wesley


--
Wesley Schwengle