Merge the 0.68 release branchlet to master.

[PuTTY.git] / CHECKLST.txt

diff --git a/CHECKLST.txt b/CHECKLST.txt
index f4d412039b4d91b8e319cd8fcf5994733fb29c09..6d3cbee586f45b795c7d3b1121a92653400c8c76 100644 (file)
--- 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.