From: dana <dana@dana.is>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: zsh-workers@zsh.org
Subject: Re: Test release: 5.7.1-test-1
Date: Mon, 16 Dec 2019 16:11:13 -0600 [thread overview]
Message-ID: <D4CBAF2B-9D86-4199-9D05-FD7860B04375@dana.is> (raw)
In-Reply-To: <20191216035514.jj7bem3dspnmhdu4@tarpaulin.shahaf.local2>
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@
next prev parent reply other threads:[~2019-12-16 22:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-14 19:20 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D4CBAF2B-9D86-4199-9D05-FD7860B04375@dana.is \
--to=dana@dana.is \
--cc=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).