Merge pull request tahoe-lafs#1415 from meejah/4096.release-1.20-round-three

4096: release 1.20.0

Author: meejah

NEWS.rst

@@ -5,8 +5,56 @@ User-Visible Changes in Tahoe-LAFS
 ==================================
 
 .. towncrier start line
-Release 1.190 (2024-01-04)
-''''''''''''''''''''''''''
+
+
+Release 1.20.0 (2024-12-03)
+'''''''''''''''''''''''''''
+
+Backwards Incompatible Changes
+------------------------------
+
+- Properly interpret "tahoe create --storage-dir" as an option.
+
+  Versions 1.19.0 and older interpreted "--storage-dir" as a "flag" and thus wouldn't work properly. (`#4110 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4110>`_)
+
+
+Features
+--------
+
+- Continued work to make Tahoe-LAFS take advantage of multiple CPUs. (`#4072 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4072>`_)
+- Mutable directories can now be created with a pre-determined "signature key" via the web API using the "private-key=..." parameter. The "private-key" value must be a DER-encoded 2048-bit RSA private key in urlsafe base64 encoding. (`#4094 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4094>`_)
+
+
+Bug Fixes
+---------
+
+- Upgrade CBOR, fixing encoding on 65KiB++ strings (`#4087 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4087>`_)
+- Stop using the C version of the cbor2 decoder. (`#4088 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4088>`_)
+- Fix incompatibility with cryptography 43. (`#4100 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4100>`_)
+- Fix incompatibility with attrs 24.1. (`#4101 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4101>`_)
+
+
+Dependency/Installation Changes
+-------------------------------
+
+- Now using the "hatch" build system, and pyproject.toml (exclusively) (`#4133 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4133>`_)
+
+
+Documentation Changes
+---------------------
+
+- Tahoe-LAFS manual's table of contents page has been reorganized. (`#3636 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3636>`_)
+- Add a global Sphinx generated glossary. Link the static GBS glossary to the global glossary. (`#4116 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4116>`_)
+
+
+Misc/Other
+----------
+
+- `#3636 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3636>`_, `#4076 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4076>`_, `#4082 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4082>`_, `#4085 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4085>`_, `#4090 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4090>`_, `#4091 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4091>`_, `#4092 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4092>`_, `#4093 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4093>`_, `#4114 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4114>`_, `#4115 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4115>`_, `#4126 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4126>`_, `#4130 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4130>`_, `#4132 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4132>`_, `#4134 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4134>`_, `#4141 <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4141>`_
+
+
+Release 1.19.0 (2024-01-04)
+'''''''''''''''''''''''''''
 
 Features
 --------

docs/release-checklist.rst

@@ -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* username@tahoe-lafs.org:/home/source/downloads
+    - scp dist/*1.20.0* username@tahoe-lafs.org:/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 (tahoe-dev@lists.tahoe-lafs.org). 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 (tahoe-dev@lists.tahoe-lafs.org).
 
 
 mailing-lists
 `````````````
 
 A new Tahoe release is traditionally announced on our mailing-list
-(tahoe-dev@tahoe-lafs.org). The former version of these instructions
-also announced the release on the following other lists:
+(tahoe-dev@lists.tahoe-lafs.org).  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:
 
 - tahoe-announce@tahoe-lafs.org
 - twisted-python@twistedmatrix.com

newsfragments/3636.documentation

@@ -1,6 +1,6 @@
 let
   pname = "tahoe-lafs";
-  version = "1.19.0.post1";
+  version = "1.20.0.post1";
 in
 { lib
 , pythonPackages

newsfragments/4072.feature

@@ -226,6 +226,7 @@ testenv = [
 # Here are the library dependencies of the test suite.
 test = [
     "mock",
+    "tox",
     "pytest",
     "pytest-twisted",
     "tox >= 4.0.0",