Zsh Mailing List Archive
Messages sorted by:
Re: Test release: 5.7.1-test-1
Peter Stephenson wrote on Sun, Dec 15, 2019 at 18:28:56 +0000:
> The only crucial issue with release numbers is that in X.Y.Z-blah-N the
> N should increment before the Z, the Z before the Y, the Y before the X,
> so that it's always clear what order they come in, and the text in
> "-blah-" isn't important because there's no obvious way to guarantee
At this point, why don't we change it to X.Y.Z.N-blah so it's clear and
unambiguous? For example, 5.8 is released as stable, then master becomes
126.96.36.199-dev (notice the extra zero), then there might be a 5.8.1 and master
will afterwards become 188.8.131.52-dev, and 184.108.40.206-dev after a wordcode bump, then
220.127.116.11-test and so on.
dana wrote on Sun, Dec 15, 2019 at 19:21:37 -0600:
> +++ b/Etc/creating-a-release.txt
> @@ -6,15 +6,28 @@ To create a zsh release:
> + The version-number sequence is as follows:
> + 5.6.2, 5.6.2-dev-0, 5.6.2-dev-1, 5.6.2-test-2, 5.6.2-test-3, 5.7
> + For -test- releases, you may update the FAQ, README, etc., to refer to the
> + appropriate stable version number.
What is the appropriate version stable version number?
> - After uploading, select the tar.xz artifact, press the 🛈 button ("View Details") to its right, and press [Select All] next to "Default Download For:". This should cause sf.net to offer that artifact in the "Looking for the latest version?" line.
> + For stable releases only, after uploading, select the tar.xz artifact
> + under zsh/, press the 🛈 button ("View Details") to its right, and
> + press [Select All] next to "Default Download For:". This should cause
> + sf.net to offer that artifact in the "Looking for the latest version?"
> + line.
Please keep whitespace/wrapping changes and substantive changes in separate
commits. They are otherwise hard to review.
> -- Upload the build artefacts to zsh.org/pub; you may need assistance from
> - another dev if you don't have access to do this.
> +- For stable releases, upload the build artefacts to zsh.org/pub; you may need
> + assistance from another dev if you don't have access to do this.
In principle, it'll be nice to have archived copies of all tarballs, but making this
optional while few developers can do the upload makes sense.
Messages sorted by: