mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
A couple of release-checklist updates.
I thought of a couple more things it's worth double-checking at release time, and also, moved the 'merge to main' instructions from the RC build step to the final release phase, because that way they don't have to be pointlessly redone if commits have appeared on main in between.
This commit is contained in:
parent
751671d73a
commit
56458a1491
17
CHECKLST.txt
17
CHECKLST.txt
@ -76,9 +76,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 main.
|
||||
|
||||
- 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
|
||||
@ -119,6 +116,10 @@ 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 testsc
|
||||
@ -194,12 +195,18 @@ locally, this is the procedure for putting it up on the web.
|
||||
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 main 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 main # update the main branch
|
||||
git push origin --tags # should push the new release tag
|
||||
|
Loading…
Reference in New Issue
Block a user