1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
To create a zsh release:
- Be satisfied that 'master' is releaseable.
(No recent destabilizing changes, `make check` passes, etc)
- Bump or update:
Config/version.mk to today's date
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, .... No
special release process is associated with a -dev version bump.
- Usually at least one -test version is released for public testing in
the lead-up to the final release of the next stable version.
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.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.8.1..." (not "5.8.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.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.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 ...
make -C Etc
make -C Doc everything
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:
git clone git://git.code.sf.net/p/zsh/web
git clone ssh://git.code.sf.net/p/zsh/web
- Upload to sf.net:
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.
- If the new release is a stable release, update zsh.sf.net:
# Move into the 'web' repository mentioned above
cd /path/to/web/repo
git pull
# Review the README, in case there is any new information there
cat README
# Run release.zsh to update the documentation from the main repository
# (making sure you still have checked out the tag you created!)
ZSHPATH=/path/to/zsh/repo ./release.zsh
# Commit changes
git commit -am 'Doc, FAQ, Intro: Update for <version>' # replace <version>
# Update the files mentioned in the release.zsh instructions (just
# adhere to the existing structure/format)
$EDITOR index.html
$EDITOR News/index.html
$EDITOR releases.html
# Run release-update-versions.zsh to update the names and sizes of the
# files listed on the documentation index and source page
./release-update-versions.zsh <version> # replace <version>
# Commit changes
git commit -am 'Update downloads, notes, etc., for <version>' # replace <version>
# Tag and push changes
git tag -sm 'Release of zsh <version>' zsh-<version> # replace <version>
git push
# Post changes; see web/README for the full rsync command. When in
# doubt, use `rsync -n` to perform a dry run. Note that changes may take
# 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.
- Post to -workers@
- After a day or so post to:
-users@, if test release;
-announce@, if stable release.
|
