diff options
Diffstat (limited to 'CHECKLST.txt')
| -rw-r--r-- | CHECKLST.txt | 64 |
1 files changed, 47 insertions, 17 deletions
diff --git a/CHECKLST.txt b/CHECKLST.txt index 5e9a7a08..3d618cbd 100644 --- a/CHECKLST.txt +++ b/CHECKLST.txt @@ -8,7 +8,7 @@ When we begin to work towards a release and want to enable pre-releases on the website: - Make a branch whose tip will be the current state of the - pre-release. Regardless of whether the branch is from master or + pre-release. Regardless of whether the branch is from main or from a prior release branch, the name of the branch must now be in the form 'pre-X.YZ', or else the website will fail to link to it properly in gitweb and the build script will check out the wrong @@ -31,11 +31,26 @@ Things to do during the branch-stabilisation period: word XXX-REVIEW-BEFORE-RELEASE. (Any such comments should state clearly what needs to be done.) - - Do some testing of the Windows version with Minefield (you can - build a Minefield version using 'bob . XFLAGS=-DMINEFIELD'), and of - the Unix version with valgrind and/or Address Sanitiser. In - particular, any headline features for the release should get a - workout with memory checking enabled! + - Test the Unix build with Address Sanitiser. In particular, any + headline features for the release should get a workout with memory + checking enabled! + + - Test the Windows build with Address Sanitiser too (as of VS 2022). + + In the course of that, give a recent Windows pterm a try, to + make sure that still works. + + - Test building and running on old platforms: + + build on Debian stretch (containing CMake 3.7, the earliest + CMake we claim support for) + + build with all three major versions of GTK + + build the old-Windows binaries and test-run them on Win95 (PuTTY + proper even without WinSock2) + + - Check Coverity is happy. + + - Check the side-channel tester is happy. + + - Check all the non-SSH network backends still basically work. Making a release candidate build -------------------------------- @@ -73,9 +88,6 @@ Making a release candidate build - Make the release tag, pointing at the version-update commit we just generated. - - If the release is on a branch (which I expect it generally will - be), merge that branch to master. - - Make a release-candidate build from the release tag, and put the build.out and build.log files somewhere safe. Normally I store these inside the ~/src/putty/X.YZ directory, alongside the git @@ -108,7 +120,7 @@ Making a release candidate build * make sure they basically work * check they report the right version number * if there's any easily observable behaviour difference between - the release branch and master, arrange to observe it + the release branch and main, arrange to observe it * test that the Windows installer installs successfully + on x86 and Arm, and test that putty.exe runs in both cases * test that the Unix source tarball unpacks and builds @@ -116,9 +128,13 @@ Making a release candidate build also try Debian sid + test-build with all of GTK 1, 2 and 3 + test-build with -DNOT_X_WINDOWS + * test that the Windows source builds with Visual Studio (just in + case there's an unguarded clangism that would prevent it) + * quick check of the outlying network protocols (Telnet, SUPDUP + etc) * feed the release-candidate source to Coverity and make sure it didn't turn up any last-minute problems - * make sure we have a clean run of sctest + * make sure we have a clean run of testsc * do some testing on a system with a completely clean slate (no prior saved session data) @@ -180,25 +196,28 @@ locally, this is the procedure for putting it up on the web. - Check that downloads via version-numbered URLs all work: ../putty/release.pl --version=X.YZ --precheck - If this has trouble accessing chiark's ftp server, that is - unfortunately normal; add --no-ftp and try again. - Switch the 'latest' links over to the new release: * Update the HTTP redirect at the:www/putty/htaccess . - * Update the FTP symlink at chiark:ftp/putty-latest . - Now verify that downloads via the 'latest' URLs are all redirected correctly and work: ../putty/release.pl --version=X.YZ --postcheck + - If the release is on a branch (which I expect it generally will + be), merge that branch to main, so that the 'update version number' + change appears on main and the snapshots start announcing + themselves as post-X.YZ. + - Push all the git repositories: * run 'git push' in the website checkout * run 'git push' in the wishlist checkout * push from the main PuTTY checkout. Typically this one will be - pushing both the release tag and an update to the master branch, - plus removing the pre-release branch, so you'll want some + pushing both the release tag and the merge we just made to the + main branch, plus removing the pre-release branch, so you'll + want some commands along these lines: - git push origin master # update the master branch + git push origin main # update the main branch git push origin --tags # should push the new release tag git push origin :pre-X.YZ # delete the pre-release branch @@ -216,6 +235,17 @@ locally, this is the procedure for putting it up on the web. subdirectory for the new version and that the links from its latest.html point into that subdirectory. + - Start the process of updating our Windows Store entry: + + log into partner.microsoft.com and go to Partner Center + + start editing the existing app submission, which should + automatically create a new submission + * provide a new set of installer URLs, then click "save all" + which actually uploads them + * change the "what's new in this release" text in the store + listing + * upload revised screenshots, if necessary + + press Publish to submit that to the actual upload process + - Announce the release! + Construct a release announcement email whose message body is the announcement written above, and which includes the following |