Re: Test release: 5.7.1-test-1

[Daniel Shahaf <d.s@daniel.shahaf.name>]

dana wrote on Sat, Dec 14, 2019 at 22:32:57 -0600:
> On 14 Dec 2019, at 21:58, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > README shouldn't say "This is version 5.8.  It is a stable
> > release." yet.  The tarball is 5.7.1-test-1, not 5.8, and it's a test
> > release, not stable release; that's what README should state.
> 
> Oh. I had just copied what we did for 5.7:
> 
> https://github.com/zsh-users/zsh/commit/9dbde9e9c7d22ee0d301e4a2fecf97906d1ddce9
> 
> If that's undesirable, i'll add it to the release instructions later.

Ah, I didn't realize there was precedent for that.

I _still_ think -test- tarballs should not describe themselves as the final
release, but if we have precedent for doing things differently then
perhaps there's a good reason for that that I'm overlooking.

> On a related note, i also wasn't clear on how the -dev- and -test- numbering
> are meant to work. Previous first -test- releases have either reset the number
> to 1 or incremented the last -dev- number (e.g., -dev-1 to -test-2). The
> release instructions say -dev-$((i++)) and -test-$((++j)), which i guess means
> start from -dev-0 and -test-1, but it's not quite explicit. Is that correct?

Yes, that's the intended meaning, and yes, I could've written it more
explicitly.

> (If they do have different 'base indexes', why?)

I just documented what I had determined to be precedent from looking at
git history at the time of writing.  I'm not aware of any reason beyond
this.  I do think, however, that the version number of master should
increase chronologically.  I assume most packaging systems would
consider any test version number as larger than any (hypothetical) dev
version because 'dev' < 'test' as ASCII strings (i.e., as determined by
strcmp(3)); for example, Debian:

    $ dpkg --compare-versions '5.7.1-dev-9' lt '5.7.1-test-0' && echo yes
    yes
    $ 

This implies that the release after ${V}-dev-5 could be either
${V}-test-1 or ${V}-test-6, insofar as version number ordering is
concerned.  I don't have a strong preference between these two.

> Lastly, should the 'latest version' on Sourceforge be updated to point to test
> releases, or only stable ones? The instructions didn't make a distinction, so
> i updated it, but that's another thing that might be made more explicit.

Actually, I'd err on the side of *not* updating it, since it's what SF
offers as the default download, and we don't want people to download
test releases unless they opt-in to that.

No fault to you for guessing wrongly — on the contrary, kudos for taking
action and asking on-list afterwards — but I suggest that you revert
this.  You can do this by selecting zsh-5.7.1.tar.xz in the file manager
and clicking the "Make this the recommended version" button in the UI (I
don't remember the exact phrasing).

If there's a separate "Recommended beta version" thing, we could use
that.  Otherwise, 5.7.1 should remain the recommended production/stable
version until 5.8 comes along.

> PS: You might've noticed that i also forgot to update the change log before
> tagging; i can't blame that on confusion, i just messed up :(

No worries.  Just make sure it's documented clearly in the checklist for
next time ☺

Cheers,

Daniel