forked from tahoe-lafs/tahoe-lafs
-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request tahoe-lafs#1415 from meejah/4096.release-1.20-roun…
…d-three 4096: release 1.20.0
- Loading branch information
Showing
31 changed files
with
115 additions
and
142 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,7 +3,7 @@ | |
Release Checklist | ||
================= | ||
|
||
This release checklist specifies a series of checks that anyone engaged in | ||
This release checklist specifies a series of checks that anyone engaged in | ||
releasing a version of Tahoe should follow. | ||
|
||
Any contributor can do the first part of the release preparation. Only | ||
|
@@ -39,19 +39,19 @@ Tuesday if you want to get anything in"). | |
Get a clean checkout | ||
```````````````````` | ||
|
||
The release proccess involves compressing source files and putting them in formats | ||
suitable for distribution such as ``.tar.gz`` and ``zip``. That said, it's neccesary to | ||
The release proccess involves compressing source files and putting them in formats | ||
suitable for distribution such as ``.tar.gz`` and ``zip``. That said, it's neccesary to | ||
the release process begins with a clean checkout to avoid making a release with | ||
previously generated files. | ||
|
||
- 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). | ||
- 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). | ||
|
||
.. note:: | ||
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 | ||
.. note:: | ||
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 | ||
practice to give it the release name. You MAY also discard this directory once the release | ||
process is complete. | ||
|
||
Get into the release directory and install dependencies by running | ||
Get into the release directory and install dependencies by running: | ||
|
||
- cd ../tahoe-release-x.x.x (assuming you are still in your original clone) | ||
- python -m venv venv | ||
|
@@ -61,94 +61,68 @@ Get into the release directory and install dependencies by running | |
Create Branch and Apply Updates | ||
``````````````````````````````` | ||
|
||
- Create a branch for the release/candidate (e.g. ``XXXX.release-1.16.0``) | ||
- run tox -e news to produce a new NEWS.txt file (this does a commit) | ||
- create the news for the release | ||
|
||
- newsfragments/<ticket number>.minor | ||
- commit it | ||
|
||
- manually fix NEWS.txt | ||
- Create a branch for the release/candidate: git checkout -b XXXX.release-1.16.0 | ||
- produce a new NEWS.txt file (this does a commit): tox -e news | ||
- create the news for the release: | ||
- touch newsfragments/<ticket number>.minor | ||
- git add newsfragments/<ticket number>.minor | ||
- git commit -m news | ||
|
||
- manually fix ``NEWS.txt``: | ||
- proper title for latest release ("Release 1.16.0" instead of "Release ...post1432") | ||
- double-check date (maybe release will be in the future) | ||
- spot-check the release notes (these come from the newsfragments | ||
files though so don't do heavy editing) | ||
- spot-check the release notes (these come from the newsfragments files though so don't do heavy editing) | ||
- commit these changes | ||
|
||
- update "relnotes.txt" | ||
|
||
- update ``relnotes.txt``: | ||
- update all mentions of ``1.16.0`` to new and higher release version for example ``1.16.1`` | ||
- update "previous release" statement and date | ||
- summarize major changes | ||
- commit it | ||
|
||
- update "nix/tahoe-lafs.nix" | ||
|
||
- update ``nix/tahoe-lafs.nix``: | ||
- change the value given for `version` from `OLD.post1` to `NEW.post1` | ||
|
||
- update "docs/known_issues.rst" if appropriate | ||
- update ``docs/known_issues.rst`` if appropriate | ||
- Push the branch to github | ||
|
||
- Create a (draft) PR; this should trigger CI (note that github | ||
doesn't let you create a PR without some changes on the branch so | ||
running + committing the NEWS.txt file achieves that without changing | ||
any code) | ||
- Confirm CI runs successfully on all platforms | ||
|
||
|
||
Create Release Candidate | ||
```````````````````````` | ||
|
||
Before "officially" tagging any release, we will make a | ||
release-candidate available. So there will be at least 1.15.0rc0 (for | ||
example). If there are any problems, an rc1 or rc2 etc may also be | ||
released. Anyone can sign these releases (ideally they'd be signed | ||
"officially" as well, but it's better to get them out than to wait for | ||
that). | ||
|
||
Typically expert users will be the ones testing release candidates and | ||
they will need to evaluate which contributors' signatures they trust. | ||
|
||
- (all steps above are completed) | ||
- sign the release | ||
|
||
- git tag -s -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A -m "release Tahoe-LAFS-1.16.0rc0" tahoe-lafs-1.16.0rc0 | ||
|
||
.. note:: | ||
- Replace the key-id above with your own, which can simply be your email if it's attached to your fingerprint. | ||
- Don't forget to put the correct tag message and name. In this example, the tag message is "release Tahoe-LAFS-1.16.0rc0" and the tag name is ``tahoe-lafs-1.16.0rc0`` | ||
Create The Release | ||
`````````````````` | ||
|
||
- build all code locally | ||
|
||
- these should all pass: | ||
|
||
- tox -e py37,codechecks,docs,integration | ||
- tox -e py311,codechecks,docs,integration | ||
|
||
- these can fail (ideally they should not of course): | ||
|
||
- tox -e deprecations,upcoming-deprecations | ||
|
||
- clone to a clean, local checkout (to avoid extra files being included in the release) | ||
|
||
- cd /tmp | ||
- git clone /home/meejah/src/tahoe-lafs | ||
- install build dependencies | ||
|
||
- build tarballs | ||
- pip install -e .[build] | ||
|
||
- tox -e tarballs | ||
- Confirm that release tarballs exist by runnig: | ||
- build tarball + wheel (should be built into dist/) | ||
|
||
- ls dist/ | grep 1.16.0rc0 | ||
- hatchling build | ||
|
||
- inspect and test the tarballs | ||
|
||
- install each in a fresh virtualenv | ||
- run `tahoe` command | ||
- install each in a fresh virtualenv | ||
- run `tahoe` command | ||
|
||
- when satisfied, sign the tarballs: | ||
|
||
- gpg --pinentry=loopback --armor -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A --detach-sign dist/tahoe_lafs-1.16.0rc0-py2.py3-none-any.whl | ||
- gpg --pinentry=loopback --armor --detach-sign dist/tahoe_lafs-1.16.0rc0.tar.gz | ||
- gpg --pinentry=loopback --armor -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A --detach-sign dist/tahoe_lafs-1.20.0rc0-py2.py3-none-any.whl | ||
- gpg --pinentry=loopback --armor --detach-sign dist/tahoe_lafs-1.20.0rc0.tar.gz | ||
|
||
|
||
Privileged Contributor | ||
|
@@ -175,14 +149,14 @@ Sign Git Tag | |
Upload Artifacts | ||
```````````````` | ||
|
||
Any release-candidate or actual release plus signature (.asc file) | ||
need to be uploaded to https://tahoe-lafs.org in `~source/downloads` | ||
Any release plus signature (.asc file) need to be uploaded to | ||
https://tahoe-lafs.org in `~source/downloads` | ||
|
||
- secure-copy all release artifacts to the download area on the | ||
tahoe-lafs.org host machine. `~source/downloads` on there maps to | ||
https://tahoe-lafs.org/downloads/ on the Web: | ||
|
||
- scp dist/*1.15.0* [email protected]:/home/source/downloads | ||
- scp dist/*1.20.0* [email protected]:/home/source/downloads | ||
|
||
- the following developers have access to do this: | ||
|
||
|
@@ -192,13 +166,13 @@ need to be uploaded to https://tahoe-lafs.org in `~source/downloads` | |
|
||
Push the signed tag to the main repository: | ||
|
||
- git push origin tahoe-lafs-1.17.1 | ||
- git push origin tahoe-lafs-1.20.0 | ||
|
||
For the actual release, the tarball and signature files need to be | ||
uploaded to PyPI as well. | ||
|
||
- ls dist/*1.19.0* | ||
- twine upload --username __token__ --password `cat SECRET-pypi-tahoe-publish-token` dist/*1.19.0* | ||
- ls dist/*1.20.0* | ||
- twine upload --username __token__ --password `cat SECRET-pypi-tahoe-publish-token` dist/*1.20.0* | ||
|
||
The following developers have access to do this: | ||
|
||
|
@@ -207,47 +181,29 @@ The following developers have access to do this: | |
- exarkun (partial?) | ||
|
||
|
||
Announcing the Release Candidate | ||
```````````````````````````````` | ||
|
||
The release-candidate should be announced by posting to the | ||
mailing-list ([email protected]). For example: | ||
https://lists.tahoe-lafs.org/pipermail/tahoe-dev/2020-October/009978.html | ||
|
||
|
||
Is The Release Done Yet? | ||
Merge the Release Branch | ||
```````````````````````` | ||
|
||
If anyone reports a problem with a release-candidate then a new | ||
release-candidate should be made once a fix has been merged to | ||
master. Repeat the above instructions with `rc1` or `rc2` or whatever | ||
is appropriate. | ||
|
||
Once a release-candidate has marinated for some time then it can be | ||
made into a the actual release. | ||
|
||
The actual release follows the same steps as above, with some differences: | ||
|
||
- there is no "-rcX" on the end of release names | ||
- the release is uploaded to PyPI (using Twine) | ||
- the version is tagged in Git (ideally using "the tahoe release key" | ||
but can be done with any of the authorized core developers' personal | ||
key) | ||
- the release-candidate branches must be merged back to master after | ||
the release is official (e.g. causing newsfragments to be deleted on | ||
master, etc) | ||
Once the release has been signed and uploaded the release branch | ||
should be merged to master (thus deleting newsfragments, etc). | ||
|
||
|
||
Announcing the Release | ||
---------------------- | ||
`````````````````````` | ||
|
||
The release-candidate should be announced by posting to the | ||
mailing-list ([email protected]). | ||
|
||
|
||
mailing-lists | ||
````````````` | ||
|
||
A new Tahoe release is traditionally announced on our mailing-list | ||
([email protected]). The former version of these instructions | ||
also announced the release on the following other lists: | ||
([email protected]). For example: | ||
https://lists.tahoe-lafs.org/pipermail/tahoe-dev/2020-October/009978.html | ||
|
||
The former version of these instructions also announced the release on | ||
the following other lists: | ||
|
||
- [email protected] | ||
- [email protected] | ||
|
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
Empty file.
Empty file.
Empty file.
This file was deleted.
Oops, something went wrong.
Empty file.
Empty file.
Empty file.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
File renamed without changes.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
Empty file.
Empty file.
This file was deleted.
Oops, something went wrong.
Empty file.
Empty file.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
let | ||
pname = "tahoe-lafs"; | ||
version = "1.19.0.post1"; | ||
version = "1.20.0.post1"; | ||
in | ||
{ lib | ||
, pythonPackages | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.