Re: Test release: 5.7.1-test-1

[dana <dana@dana.is>]

On 15 Dec 2019, at 12:28, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> I've tended to put the final details in release documentation for test
> releases so that people can check it before the release.  Otherwise it's
> easy to miss something at the last minute, and then it's too late.

(Didn't get this in my in-box for some reason)

That makes sense to me, personally. And it is a test release for the next
version, after all, not for the previous one (though i can see how the
'stable' bit in the README might be confusing). I've incorporated this and the
incrementing thing into the document below, but obv we can discuss further if
necessary

dana


diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
index dfde269ae..059c2aced 100644
--- a/Etc/creating-a-release.txt
+++ b/Etc/creating-a-release.txt
@@ -6,15 +6,28 @@ To create a zsh release:
 - Bump or update:
 
 	Config/version.mk to today's date
-	Config/version.mk version number (sequence: 5.4.2, 5.4.2-dev-$((i++)), 5.4.2-test-$((++j)), 5.5)
+	Config/version.mk version number
 	Etc/FAQ.yo
 	README
 	NEWS
 
+  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
+
+  (Note the unbroken last-digit sequence going from -dev- to -test-.)
+
+  Usually there is only one -dev- version (-dev-0), but the last digit may be
+  incremented if for example there is a wordcode compatibility break, as in the
+  real-world example given above.
+
   README should document compatibility-breaking changes. Generally, NEWS should
   document new features and major bug fixes (but not routine fixes or changes to
   completion/contrib functions).
 
+  For -test- releases, you may update the FAQ, README, etc., to refer to the
+  appropriate stable version number.
+
 - Commit those changes with an "unposted" ChangeLog entry.
 
 	git commit -am "Test release: 5.5.1-test-1." &&
@@ -45,16 +58,21 @@ To create a zsh release:
 	make tarxz-doc tarxz-src
 	for i in zsh*.tar.?z ; do gpg -ab -- $i ; done
 
-- [one time step] Add your key to http://zsh.sf.net/Arc/source.html; see README in the 'web' repository for how to do this.  Its URL is:
+- [one time step] Add your key to http://zsh.sf.net/Arc/source.html; see README
+  in the 'web' repository for how to do this.  Its URL is:
 
 	git clone git://git.code.sf.net/p/zsh/web
 	git clone ssh://git.code.sf.net/p/zsh/web
 
-- Upload to sf.net
+- Upload to sf.net:
 
 	Test releases go to the "zsh-test" directory.
 	Stable releases to zsh/ and zsh-doc/.
-	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.
 
 - If the new release is a stable release, update zsh.sf.net:
 
@@ -94,8 +112,8 @@ To create a zsh release:
 	# several minutes to appear afterwards
 	rsync ...
 
-- 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.
 
 - Post to -workers@