Amber,
Can we have a new Twisted release within the next two months, say in Nov./Dec. timeframe, or
sooner if you'd like?
Given that Amber hasn't been super responsive lately, and that I firmly believe it should be possible to take breaks from open source (particularly amidst the, you know, global collapse of civilization and stuff), I will take the opportunity point out yet again that
http://twisted.readthedocs.org/en/latest/core/development/policy/release-process.html documents the release process and any sufficiently-motivated volunteer (with at least a
bit of history & trust within the community) can step forward and receive all the permissions necessary to do all of these steps.
I will personally volunteer to fill in the permissions gaps for any interested parties, although I don't have much bandwidth for the release itself.
Amber, if you want to do it, go ahead and get started, I'm just saying we don't need to put this on your shoulders :).
Hi,
To me, the current release process seems complicated and requires manual work and I think that the release document needs some update.
The release documentation starts with "Tarballs for Twisted as a whole, and for each of its sub-projects".
Is that still the case?
Maybe the release can be simplified and automated:
* Build the source and binary wheel in GitHub actions as this can be done for Linux (Ubuntu), Windows and macOS.
* Host the download source and wheel files only on PyPi and publish them automatically from GitHub action on a new tag is created.
* Host the documentation only on the Read The Docs.
* Hos the API documentation on Read The Docs - might need some hacking, but at release we can create an API docs package as an artifact which is then pulled when Read The Docs documentation is created and copied as extra HTML files.
* Move Twisted blog to GitHub pages... or even read the docs with a separate theme like Crate [1] ... if the blog is still required.
------
With the above implemented the release should look like:
* Each time the tests for a PR are executed, pydoctor will run and automatically create the API files as an artifact available for download.
* Manually create a new branch in which the version is updated and the changelog/news/release note is created and all the news fragment files are removed/ . Have the branch reviewed and approved with all the tests passed. When the pydoctor tests are executed, the API docs are created.
* The release branches can have a naming convention line 'release-20.0.0`. At first the release branch can have a release candidate version and a GitHub can automatically push the release to PyPi.
* Manually send an email to Twisted mailing list to announce the pre-release.
* Once the branch is merged, manually push a new tag
* The new tag should trigger the GitHub action for publishing the release on PyPi
* The new merge in master should trigger the Read The Docs build... which now will also include the static API docs pages.
* Once the release is done, manually send a new email to the mailing list.
There are still many manual steps, but the only permissions required is commit to the repo.
This will no longer use any of the Twisted own infrastructure.
--
Adi Roiban