From 1c1419bfce92bbdf70489a502bb2b2ba84690f39 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Sat, 18 Feb 2017 17:06:46 +0000 Subject: [PATCH] Release checklist updates. These reflect the fact that I'm increasingly preferring to make a release-candidate build a few days in advance of the actual release, and give the team time to do a bit of testing on it before putting it up on the live website. Hence, I can't _quite_ fill in everything in the website announcement ahead of time - the release date has to wait until we know what it is, which means I need to have 'now fill in the release date' as part of the go-live checklist. Also, I've provided a better bob command for doing a release build (putting it somewhere safe to begin with, rather than leaving it precariously in my normal build directory). And while I'm here, I've standardised all my placeholder version numbers to X.YZ; previously half of them said 0.XX :-) --- CHECKLST.txt | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/CHECKLST.txt b/CHECKLST.txt index f4d41203..6d3cbee5 100644 --- a/CHECKLST.txt +++ b/CHECKLST.txt @@ -79,8 +79,11 @@ for it: - Update the website, in a local checkout: * Write a release file in components/releases which identifies the - new version, its release date, a section for the Changes page, - and a news announcement for the front page. + new version, a section for the Changes page, and a news + announcement for the front page. + + The one thing this can't yet contain is the release date; + that has to be put in at the last minute, when the release + goes live. Fill in 'FIXME', for the moment. * Disable the pre-release sections of the website (if previously enabled), by editing prerel_version() in components/Base.mc to return undef. @@ -95,15 +98,16 @@ for it: headers for those. * Add an entry to the @releases array in control/bugs2html. - - Build the release, by checking out the release tag: - git checkout 0.XX - bob . RELEASE=0.XX + - Make a release-candidate build from the release tag, and put the + build.out and build.log dfiles somewhere safe. Normally I store + these in an adjacent directory, so I'll run a command like + bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ This should generate a basically valid release directory as - `build.out/putty', and provide link maps and sign.sh alongside that - in build.out. + `build-X.YZ-rcN.out/putty', and provide link maps and sign.sh + alongside that. - - Double-check in build.log that the release was built from the right - git commit. + - Double-check in build-X.YZ-rcN.log that the release was built from + the right git commit. - Do a bit of checking of the release binaries: * make sure they basically work @@ -113,16 +117,22 @@ for it: * test the Windows installer * test the Unix source tarball. - - Sign the release: in the `build.out' directory, type + - Sign the release: in the `build-X.YZ-rcN.out' directory, type sh sign.sh -r putty and enter the passphrases a lot of times. + - For my own safety, make the release candidate build read-only. + chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log + The actual release procedure ---------------------------- Once all the above preparation is done and the release has been built locally, this is the procedure for putting it up on the web. + - Make a final adjustment to your local website changes, filling in + the release date in components/releases/X.YZ.mi. + - Upload the release itself and its link maps to everywhere it needs to be, by running this in the build.out directory: ../release.pl --version=X.YZ --upload @@ -147,7 +157,7 @@ locally, this is the procedure for putting it up on the web. commands along these lines: git push origin master # update the master branch git push origin --tags # should push the new release tag - git push origin :pre-0.XX # delete the pre-release branch + git push origin :pre-X.YZ # delete the pre-release branch - Run ~/adm/puttyweb.sh on atreus to update the website after all those git pushes. -- 2.45.1