release-tools
release-tools copied to clipboard
python
Scripts for making (C)Python releases
> Might also be worth adding a type checker, which could have caught #107. _Originally posted by @JelleZijlstra in https://github.com/python/release-tools/issues/109#issuecomment-2045309417_
Python security releases usually require all Python release managers to be available due to each release stream being assigned to a specific release manager. This happens in multiple locations: *...
We also have partially automated the release process in GitHub Actions but [haven't reached the level of automation](https://github.com/python/release-tools/issues/108) that we have for Windows and Azure Pipelines. Currently `run_release` requires humans...
This makes each install test run in its own container, isolated from the build machine, which allows us to test versions of Python that are already installed on the build...
To match most of the other https://github.com/python repos. Instructions: https://github.com/github/renaming#renaming-existing-branches The branch name isn't referred to in this repo's code.
This issue assumes that Release Managers are using the `run_release.py` script, the "current" ordering is derived from that script. Implementing the proposal below would require changes to both `run_release.py` and...
To avoid needing manual PRs such as https://github.com/python/cpython/pull/109453, either [PEP 101](https://peps.python.org/pep-0101/#how-to-make-a-release) or a script such as: > * Bump version numbers via the release script: > `$ .../release-tools/release.py --bump X.Y.ZaN`...
sigstore-python v1 currently generates disjoint verification materials (.crt/.sig) and bundles (.sigstore). v2 only generates bundles by default, and bundles are going to be the verification material of choice going forward....
A newly created beta branch needs a backport of https://github.com/python/cpython/issues/87891
