Re: [PATCH] add patchlevel to --version output
Wesley Schwengle <[email protected]>
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <[email protected]> |
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