zsh-workers
 help / color / mirror / code / Atom feed
773a6af8cae2c02353737a1ffe7e80c6020b19ea blob 4161 bytes (raw)

  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
 
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.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." &&
		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-...")

	git tag --sign -m "Tag version zsh-5.5.1-test-1." zsh-5.5.1-test-1

- 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
	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 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.
debug log:

solving 773a6af8c ...
found 773a6af8c in https://inbox.vuxu.org/zsh-workers/D4CBAF2B-9D86-4199-9D05-FD7860B04375@dana.is/
found dfde269ae in https://git.vuxu.org/mirror/zsh/
preparing index
index prepared:
100644 dfde269ae5496d2c3ac9ea7e56b33dcf9f65ec13	Etc/creating-a-release.txt

applying [1/1] https://inbox.vuxu.org/zsh-workers/D4CBAF2B-9D86-4199-9D05-FD7860B04375@dana.is/
diff --git a/Etc/creating-a-release.txt b/Etc/creating-a-release.txt
index dfde269ae..773a6af8c 100644

Checking patch Etc/creating-a-release.txt...
Applied patch Etc/creating-a-release.txt cleanly.

index at:
100644 773a6af8cae2c02353737a1ffe7e80c6020b19ea	Etc/creating-a-release.txt

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