| 1 | |
|---|
| 2 | ================= |
|---|
| 3 | Release Checklist |
|---|
| 4 | ================= |
|---|
| 5 | |
|---|
| 6 | This release checklist specifies a series of checks that anyone engaged in |
|---|
| 7 | releasing a version of Tahoe should follow. |
|---|
| 8 | |
|---|
| 9 | Any contributor can do the first part of the release preparation. Only |
|---|
| 10 | certain contributors can perform other parts. These are the two main |
|---|
| 11 | sections of this checklist (and could be done by different people). |
|---|
| 12 | |
|---|
| 13 | A final section describes how to announce the release. |
|---|
| 14 | |
|---|
| 15 | This checklist is based on the original instructions (in old revisions in the file |
|---|
| 16 | `docs/how_to_make_a_tahoe-lafs_release.org`). |
|---|
| 17 | |
|---|
| 18 | |
|---|
| 19 | Any Contributor |
|---|
| 20 | =============== |
|---|
| 21 | |
|---|
| 22 | Anyone who can create normal PRs should be able to complete this |
|---|
| 23 | portion of the release process. |
|---|
| 24 | |
|---|
| 25 | |
|---|
| 26 | Prepare for the Release |
|---|
| 27 | ``````````````````````` |
|---|
| 28 | |
|---|
| 29 | The `master` branch should always be releasable. |
|---|
| 30 | |
|---|
| 31 | It may be worth asking (on IRC or mailing-ist) if anything will be |
|---|
| 32 | merged imminently (for example, "I will prepare a release this coming |
|---|
| 33 | Tuesday if you want to get anything in"). |
|---|
| 34 | |
|---|
| 35 | - Create a ticket for the release in Trac |
|---|
| 36 | - Ticket number needed in next section |
|---|
| 37 | - Making first release? See `GPG Setup Instructions <gpg-setup.rst>`__ to make sure you can sign releases. [One time setup] |
|---|
| 38 | |
|---|
| 39 | Get a clean checkout |
|---|
| 40 | ```````````````````` |
|---|
| 41 | |
|---|
| 42 | The release proccess involves compressing source files and putting them in formats |
|---|
| 43 | suitable for distribution such as ``.tar.gz`` and ``zip``. That said, it's neccesary to |
|---|
| 44 | the release process begins with a clean checkout to avoid making a release with |
|---|
| 45 | previously generated files. |
|---|
| 46 | |
|---|
| 47 | - Inside the tahoe root dir run ``git clone . ../tahoe-release-x.x.x`` where (x.x.x is the release number such as 1.16.0). |
|---|
| 48 | |
|---|
| 49 | .. note:: |
|---|
| 50 | The above command would create a new directory at the same level as your original clone named ``tahoe-release-x.x.x``. You can name this folder however you want but it would be a good |
|---|
| 51 | practice to give it the release name. You MAY also discard this directory once the release |
|---|
| 52 | process is complete. |
|---|
| 53 | |
|---|
| 54 | Get into the release directory and install dependencies by running: |
|---|
| 55 | |
|---|
| 56 | - cd ../tahoe-release-x.x.x (assuming you are still in your original clone) |
|---|
| 57 | - python -m venv venv |
|---|
| 58 | - ./venv/bin/pip install --editable .[test] |
|---|
| 59 | |
|---|
| 60 | |
|---|
| 61 | Create Branch and Apply Updates |
|---|
| 62 | ``````````````````````````````` |
|---|
| 63 | |
|---|
| 64 | - Create a branch for the release/candidate: git checkout -b XXXX.release-1.16.0 |
|---|
| 65 | - produce a new NEWS.txt file (this does a commit): tox -e news |
|---|
| 66 | - create the news for the release: |
|---|
| 67 | - touch newsfragments/<ticket number>.minor |
|---|
| 68 | - git add newsfragments/<ticket number>.minor |
|---|
| 69 | - git commit -m news |
|---|
| 70 | |
|---|
| 71 | - manually fix ``NEWS.txt``: |
|---|
| 72 | - proper title for latest release ("Release 1.16.0" instead of "Release ...post1432") |
|---|
| 73 | - double-check date (maybe release will be in the future) |
|---|
| 74 | - spot-check the release notes (these come from the newsfragments files though so don't do heavy editing) |
|---|
| 75 | - commit these changes |
|---|
| 76 | |
|---|
| 77 | - update ``relnotes.txt``: |
|---|
| 78 | - update all mentions of ``1.16.0`` to new and higher release version for example ``1.16.1`` |
|---|
| 79 | - update "previous release" statement and date |
|---|
| 80 | - summarize major changes |
|---|
| 81 | - commit it |
|---|
| 82 | |
|---|
| 83 | - update ``nix/tahoe-lafs.nix``: |
|---|
| 84 | - change the value given for `version` from `OLD.post1` to `NEW.post1` |
|---|
| 85 | |
|---|
| 86 | - update ``docs/known_issues.rst`` if appropriate |
|---|
| 87 | - Push the branch to github |
|---|
| 88 | |
|---|
| 89 | - Create a (draft) PR; this should trigger CI (note that github |
|---|
| 90 | doesn't let you create a PR without some changes on the branch so |
|---|
| 91 | running + committing the NEWS.txt file achieves that without changing |
|---|
| 92 | any code) |
|---|
| 93 | - Confirm CI runs successfully on all platforms |
|---|
| 94 | |
|---|
| 95 | |
|---|
| 96 | Create The Release |
|---|
| 97 | `````````````````` |
|---|
| 98 | |
|---|
| 99 | - build all code locally |
|---|
| 100 | |
|---|
| 101 | - these should all pass: |
|---|
| 102 | |
|---|
| 103 | - tox -e py311,codechecks,docs,integration |
|---|
| 104 | |
|---|
| 105 | - these can fail (ideally they should not of course): |
|---|
| 106 | |
|---|
| 107 | - tox -e deprecations,upcoming-deprecations |
|---|
| 108 | |
|---|
| 109 | - install build dependencies |
|---|
| 110 | |
|---|
| 111 | - pip install -e .[build] |
|---|
| 112 | |
|---|
| 113 | - build tarball + wheel (should be built into dist/) |
|---|
| 114 | |
|---|
| 115 | - hatchling build |
|---|
| 116 | |
|---|
| 117 | - inspect and test the tarballs |
|---|
| 118 | |
|---|
| 119 | - install each in a fresh virtualenv |
|---|
| 120 | - run `tahoe` command |
|---|
| 121 | |
|---|
| 122 | - when satisfied, sign the tarballs: |
|---|
| 123 | |
|---|
| 124 | - gpg --pinentry=loopback --armor -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A --detach-sign dist/tahoe_lafs-1.20.0rc0-py2.py3-none-any.whl |
|---|
| 125 | - gpg --pinentry=loopback --armor --detach-sign dist/tahoe_lafs-1.20.0rc0.tar.gz |
|---|
| 126 | |
|---|
| 127 | |
|---|
| 128 | Privileged Contributor |
|---|
| 129 | ====================== |
|---|
| 130 | |
|---|
| 131 | Steps in this portion require special access to keys or |
|---|
| 132 | infrastructure. For example, **access to tahoe-lafs.org** to upload |
|---|
| 133 | binaries or edit HTML. |
|---|
| 134 | |
|---|
| 135 | |
|---|
| 136 | Hack Tahoe-LAFS |
|---|
| 137 | ``````````````` |
|---|
| 138 | |
|---|
| 139 | Did anyone contribute a hack since the last release? If so, then |
|---|
| 140 | https://tahoe-lafs.org/hacktahoelafs/ needs to be updated. |
|---|
| 141 | |
|---|
| 142 | |
|---|
| 143 | Sign Git Tag |
|---|
| 144 | ```````````` |
|---|
| 145 | |
|---|
| 146 | - git tag -s -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A -m "release Tahoe-LAFS-X.Y.Z" tahoe-lafs-X.Y.Z |
|---|
| 147 | |
|---|
| 148 | |
|---|
| 149 | Upload Artifacts |
|---|
| 150 | ```````````````` |
|---|
| 151 | |
|---|
| 152 | Any release plus signature (.asc file) need to be uploaded to |
|---|
| 153 | https://tahoe-lafs.org in `~source/downloads` |
|---|
| 154 | |
|---|
| 155 | - secure-copy all release artifacts to the download area on the |
|---|
| 156 | tahoe-lafs.org host machine. `~source/downloads` on there maps to |
|---|
| 157 | https://tahoe-lafs.org/downloads/ on the Web: |
|---|
| 158 | |
|---|
| 159 | - scp dist/*1.20.0* username@tahoe-lafs.org:/home/source/downloads |
|---|
| 160 | |
|---|
| 161 | - the following developers have access to do this: |
|---|
| 162 | |
|---|
| 163 | - exarkun |
|---|
| 164 | - meejah |
|---|
| 165 | - warner |
|---|
| 166 | |
|---|
| 167 | Push the signed tag to the main repository: |
|---|
| 168 | |
|---|
| 169 | - git push origin tahoe-lafs-1.20.0 |
|---|
| 170 | |
|---|
| 171 | For the actual release, the tarball and signature files need to be |
|---|
| 172 | uploaded to PyPI as well. |
|---|
| 173 | |
|---|
| 174 | - ls dist/*1.20.0* |
|---|
| 175 | - twine upload --username __token__ --password `cat SECRET-pypi-tahoe-publish-token` dist/*1.20.0* |
|---|
| 176 | |
|---|
| 177 | The following developers have access to do this: |
|---|
| 178 | |
|---|
| 179 | - warner |
|---|
| 180 | - meejah |
|---|
| 181 | - exarkun (partial?) |
|---|
| 182 | |
|---|
| 183 | |
|---|
| 184 | Merge the Release Branch |
|---|
| 185 | ```````````````````````` |
|---|
| 186 | |
|---|
| 187 | Once the release has been signed and uploaded the release branch |
|---|
| 188 | should be merged to master (thus deleting newsfragments, etc). |
|---|
| 189 | |
|---|
| 190 | |
|---|
| 191 | Announcing the Release |
|---|
| 192 | `````````````````````` |
|---|
| 193 | |
|---|
| 194 | The release-candidate should be announced by posting to the |
|---|
| 195 | mailing-list (tahoe-dev@lists.tahoe-lafs.org). |
|---|
| 196 | |
|---|
| 197 | |
|---|
| 198 | mailing-lists |
|---|
| 199 | ````````````` |
|---|
| 200 | |
|---|
| 201 | A new Tahoe release is traditionally announced on our mailing-list |
|---|
| 202 | (tahoe-dev@lists.tahoe-lafs.org). For example: |
|---|
| 203 | https://lists.tahoe-lafs.org/pipermail/tahoe-dev/2020-October/009978.html |
|---|
| 204 | |
|---|
| 205 | The former version of these instructions also announced the release on |
|---|
| 206 | the following other lists: |
|---|
| 207 | |
|---|
| 208 | - tahoe-announce@tahoe-lafs.org |
|---|
| 209 | - twisted-python@twistedmatrix.com |
|---|
| 210 | - liberationtech@lists.stanford.edu |
|---|
| 211 | - lwn@lwn.net |
|---|
| 212 | - p2p-hackers@lists.zooko.com |
|---|
| 213 | - python-list@python.org |
|---|
| 214 | - http://listcultures.org/pipermail/p2presearch_listcultures.org/ |
|---|
| 215 | - cryptopp-users@googlegroups.com |
|---|
| 216 | |
|---|
| 217 | |
|---|
| 218 | wiki |
|---|
| 219 | ```` |
|---|
| 220 | |
|---|
| 221 | Edit the "News" section of the front page of https://tahoe-lafs.org |
|---|
| 222 | with a link to the mailing-list archive of the announcement message. |
|---|
