Re: Test release: 5.7.1-test-1

[dana <dana@xxxxxxx>]

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> At this point, why don't we change it to X.Y.Z.N-blah

I like this idea if you guys do. It's easy to understand and should play well
with just about any version-comparison method. We use a similar scheme where i
work.

Pending a decision on that, though...

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Suggest: s/appropriate/upcoming/

Done

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Please keep whitespace/wrapping changes and substantive changes in separate
> commits.  They are otherwise hard to review.

Sorry, that was cheeky. I've broken the white-space changes out into a second
patch this time

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> In principle, it'll be nice to have archived copies of all tarballs

I agree, but it doesn't look like we've done that historically, so i figured
i'd just document the process we have now. I think i still don't have access
to zsh.org/pub myself (?), but if i ever get it in the future i can copy the
artefacts over from Sourceforge and update the instructions going forward

dana


diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
index dfde269ae..773a6af8c 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
+  upcoming stable version number.
+
 - Commit those changes with an "unposted" ChangeLog entry.
 
 	git commit -am "Test release: 5.5.1-test-1." &&
@@ -50,11 +63,11 @@ To create a zsh release:
 	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,7 +107,7 @@ To create a zsh release:
 	# several minutes to appear afterwards
 	rsync ...
 
-- Upload the build artefacts to zsh.org/pub; you may need assistance from
+- 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@


diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
index 773a6af8c..417799050 100644
--- a/Etc/creating-a-release.txt
+++ b/Etc/creating-a-release.txt
@@ -58,7 +58,8 @@ 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
@@ -67,7 +68,10 @@ To create a zsh release:
 
 	Test releases go to the "zsh-test" directory.
 	Stable releases to zsh/ and zsh-doc/.
-	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.
+	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:
 
@@ -107,8 +111,8 @@ To create a zsh release:
 	# several minutes to appear afterwards
 	rsync ...
 
-- 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.
+- 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@