zsh-workers
 help / color / Atom feed
* Test release: 5.7.1-test-1
@ 2019-12-14 19:20 dana
  2019-12-15  3:58 ` Daniel Shahaf
  0 siblings, 1 reply; 12+ messages in thread
From: dana @ 2019-12-14 19:20 UTC (permalink / raw)
  To: Zsh Workers List

Hello,

I've tagged 5.7.1-test-1 (test release for the up-coming zsh 5.8) and uploaded
the artefacts to:

https://sourceforge.net/projects/zsh/files/zsh-test/5.7.1-test-1

If you have the time, please test and report any issues found.

dana


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-14 19:20 Test release: 5.7.1-test-1 dana
@ 2019-12-15  3:58 ` Daniel Shahaf
  2019-12-15  4:32   ` dana
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Shahaf @ 2019-12-15  3:58 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Sat, 14 Dec 2019 19:20 +00:00:
> If you have the time, please test and report any issues found.

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.

The same goes for FAQ.yo, in case somebody builds the
documentation locally.

If you'd like to prepare the documentation update in advance, I suggest
to do it on a git branch, or to post a patch to this list.

Thanks for RM'ing, dana.

Daniel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15  3:58 ` Daniel Shahaf
@ 2019-12-15  4:32   ` dana
  2019-12-15  5:16     ` Daniel Shahaf
  0 siblings, 1 reply; 12+ messages in thread
From: dana @ 2019-12-15  4:32 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Workers List

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.

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?
(If they do have different 'base indexes', why?)

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.

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 :(

dana


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15  4:32   ` dana
@ 2019-12-15  5:16     ` Daniel Shahaf
  2019-12-15  5:50       ` dana
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Shahaf @ 2019-12-15  5:16 UTC (permalink / raw)
  To: Zsh Workers List

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15  5:16     ` Daniel Shahaf
@ 2019-12-15  5:50       ` dana
  2019-12-15 18:28         ` Peter Stephenson
  2019-12-16  1:21         ` dana
  0 siblings, 2 replies; 12+ messages in thread
From: dana @ 2019-12-15  5:50 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Workers List

On 14 Dec 2019, at 23:16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 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.

I don't feel strongly either way. Let's see if anyone else does; if not, i'll
update the instructions according to your preference.

On 14 Dec 2019, at 23:16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 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.

Maybe when you were writing the instructions you interpreted it as resetting
to 1 because we *were* incrementing it, and it just so happens that there's
usually only the one dev release (-dev-0)? If we're going to have it reset i
feel like maybe we should just use 0 for both, but i also don't feel strongly
about resetting vs incrementing. Does anyone else?

On 14 Dec 2019, at 23:16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 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.

Done. When i update the instructions, i'll make that a 'stable only' step.

dana


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15  5:50       ` dana
@ 2019-12-15 18:28         ` Peter Stephenson
  2019-12-16  3:55           ` Daniel Shahaf
  2019-12-16  1:21         ` dana
  1 sibling, 1 reply; 12+ messages in thread
From: Peter Stephenson @ 2019-12-15 18:28 UTC (permalink / raw)
  To: zsh-workers

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.

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
ordering.  Typically -dev-0 has been used to indicate a non-released
build following X.Y.Z. so the next test release would be X.Y.X-test-1,
and the release probably X.Y+1.

pws


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15  5:50       ` dana
  2019-12-15 18:28         ` Peter Stephenson
@ 2019-12-16  1:21         ` dana
  1 sibling, 0 replies; 12+ messages in thread
From: dana @ 2019-12-16  1:21 UTC (permalink / raw)
  To: Zsh Workers List; +Cc: Daniel Shahaf, Peter Stephenson

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@
 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-15 18:28         ` Peter Stephenson
@ 2019-12-16  3:55           ` Daniel Shahaf
  2019-12-16 22:11             ` dana
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Shahaf @ 2019-12-16  3:55 UTC (permalink / raw)
  To: dana; +Cc: zsh-workers

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
> ordering.

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
5.8.0.1-dev (notice the extra zero), then there might be a 5.8.1 and master
will afterwards become 5.8.1.1-dev, and 5.8.1.2-dev after a wordcode bump, then
5.8.1.3-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?

Suggest: s/appropriate/upcoming/

> -	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.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-16  3:55           ` Daniel Shahaf
@ 2019-12-16 22:11             ` dana
  2019-12-17  1:16               ` Daniel Shahaf
  0 siblings, 1 reply; 12+ messages in thread
From: dana @ 2019-12-16 22:11 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@daniel.shahaf.name> 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@daniel.shahaf.name> wrote:
> Suggest: s/appropriate/upcoming/

Done

On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@daniel.shahaf.name> 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@daniel.shahaf.name> 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@
 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-16 22:11             ` dana
@ 2019-12-17  1:16               ` Daniel Shahaf
  2019-12-20 21:26                 ` dana
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Shahaf @ 2019-12-17  1:16 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Mon, Dec 16, 2019 at 16:11:13 -0600:
> On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@daniel.shahaf.name> 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...

I'd say, go ahead with making the change unless anyone objects.  It won't
affect the numbering of stable releases so the risk of disruption is minimal.

> On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@daniel.shahaf.name> 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

Don't worry about it.

> On 15 Dec 2019, at 21:55, Daniel Shahaf <d.s@daniel.shahaf.name> 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

Thanks.  I don't have access either.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-17  1:16               ` Daniel Shahaf
@ 2019-12-20 21:26                 ` dana
  2019-12-21  8:13                   ` Daniel Shahaf
  0 siblings, 1 reply; 12+ messages in thread
From: dana @ 2019-12-20 21:26 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Workers List

On 16 Dec 2019, at 19:16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> I'd say, go ahead with making the change unless anyone objects.  It won't
> affect the numbering of stable releases so the risk of disruption is minimal.

OK, sorry, needed to let this sit for a while.

I've updated the versioning scheme per your suggestion (as i interpreted it,
at least). I also updated the example versions so it's not quite *as*
ahistorical. This is what you had in mind, right?

If there are no further issues, i will probably post another test release this
week end (per workers/45047). I'm going to stick with the current versioning
scheme until 5.8 is out, so as not to mess up any version comparisons between
5.7.x releases.

dana


diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
index dfde269ae..485d7ebaf 100644
--- a/Etc/creating-a-release.txt
+++ b/Etc/creating-a-release.txt
@@ -6,37 +6,55 @@ 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.8, 5.8.0.1-dev, 5.8.0.2-test, 5.8.1, 5.8.1.1-dev, 5.8.1.2-test, 5.9
+
+  Please note:
+
+	- All version numbers in this document are examples only and may not
+	  reflect the actual version history of the shell.
+	- A slightly different ordering of version-number components was used
+	  prior to zsh 5.8. All subsequent releases should use the scheme
+	  described above.
+	- Usually there is only one -dev version (1-dev), but there may be more
+	  if for example there is a wordcode compatibility break, in which case
+	  the sequence would be something like 1-dev, 2-dev, 3-test, ....
+
   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." &&
+	git commit -am "Test release: 5.8.1.2-test." &&
 		zshdev-add-nnnnn-and-changelog unposted
 	# (Everyone has a different way of getting the "unposted" magic string
 	# into ChangeLog and the log message.  This script is how I do it; YMMV;
 	# see Etc/zsh-development-guide for alternative scripts.)
 
-- Create signed git tag named "zsh-5.5.1-..." (not "5.5.1-...")
+- Create signed git tag named "zsh-5.8.1..." (not "5.8.1...")
 
-	git tag --sign -m "Tag version zsh-5.5.1-test-1." zsh-5.5.1-test-1
+	git tag --sign -m "Tag version zsh-5.8.1.2-test." zsh-5.8.1.2-test
 
 - If the tagged release is a stable release (as opposed to a test release):
 
-	vi Config/version.mk # bump to 5.6-dev-0 and tomorrow's date
+	vi Config/version.mk # bump to 5.9.0.1-dev and tomorrow's date
 	git commit -am "Post-release version bump." &&
 		zshdev-add-nnnnn-and-changelog unposted
 		# or local equivalent (see above)
 
 - Create tarball:
 
-	git checkout zsh-5.5.1-test-1
+	git checkout zsh-5.8.1.2-test
 	git diff HEAD # ensure no local mods
 	rm -f Doc/help.txt Doc/help/[_a-zA-Z0-9]* # some devs have had issues with these
 	Util/preconfig && ./configure ...
@@ -50,11 +68,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 +112,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 485d7ebaf..27a5b9a5a 100644
--- a/Etc/creating-a-release.txt
+++ b/Etc/creating-a-release.txt
@@ -63,7 +63,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
@@ -72,7 +73,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:
 
@@ -112,8 +116,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@
 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test release: 5.7.1-test-1
  2019-12-20 21:26                 ` dana
@ 2019-12-21  8:13                   ` Daniel Shahaf
  0 siblings, 0 replies; 12+ messages in thread
From: Daniel Shahaf @ 2019-12-21  8:13 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Fri, Dec 20, 2019 at 15:26:09 -0600:
> On 16 Dec 2019, at 19:16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > I'd say, go ahead with making the change unless anyone objects.  It won't
> > affect the numbering of stable releases so the risk of disruption is minimal.
> 
> OK, sorry, needed to let this sit for a while.
> 
> I've updated the versioning scheme per your suggestion (as i interpreted it,
> at least). I also updated the example versions so it's not quite *as*
> ahistorical. This is what you had in mind, right?

Yes, LGTM, thanks!

The only addition I can think of is to spell out somewhere when the version
number becomes *-test-*: for a prelease.

> If there are no further issues, i will probably post another test release this
> week end (per workers/45047). I'm going to stick with the current versioning
> scheme until 5.8 is out, so as not to mess up any version comparisons between
> 5.7.x releases.
> 
> dana
> 
> 
> diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
> index dfde269ae..485d7ebaf 100644
> --- a/Etc/creating-a-release.txt
> +++ b/Etc/creating-a-release.txt
> @@ -6,37 +6,55 @@ To create a zsh release:
> diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
> index 485d7ebaf..27a5b9a5a 100644
> --- a/Etc/creating-a-release.txt
> +++ b/Etc/creating-a-release.txt
> @@ -63,7 +63,8 @@ To create a zsh release:

I don't know how you're generating these diffs, but you may find «git
format-patch --stdout @{upstream}..HEAD» useful.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-14 19:20 Test release: 5.7.1-test-1 dana
2019-12-15  3:58 ` Daniel Shahaf
2019-12-15  4:32   ` dana
2019-12-15  5:16     ` Daniel Shahaf
2019-12-15  5:50       ` dana
2019-12-15 18:28         ` Peter Stephenson
2019-12-16  3:55           ` Daniel Shahaf
2019-12-16 22:11             ` dana
2019-12-17  1:16               ` Daniel Shahaf
2019-12-20 21:26                 ` dana
2019-12-21  8:13                   ` Daniel Shahaf
2019-12-16  1:21         ` dana

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git