diff --git a/docs/_static/releasing.drawio b/docs/_static/releasing.drawio index 63fdce944..5bd26bd60 100644 --- a/docs/_static/releasing.drawio +++ b/docs/_static/releasing.drawio @@ -1,117 +1,121 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/_static/releasing.drawio.png b/docs/_static/releasing.drawio.png index 4b7fd23b3..9f048426f 100644 Binary files a/docs/_static/releasing.drawio.png and b/docs/_static/releasing.drawio.png differ diff --git a/docs/dev/releasing.md b/docs/dev/releasing.md index 4de1c14d6..e924e66f1 100644 --- a/docs/dev/releasing.md +++ b/docs/dev/releasing.md @@ -11,25 +11,45 @@ A `pypdf` release contains the following artifacts: ## Who does it? `pypdf` should typically only be released by one of the core maintainers / the -core maintainer. At the moment, this is Martin Thoma. +core maintainer. At the moment, this is either Martin Thoma or pubpub-zz and stefan6419846. Any owner of the py-pdf organization also has the technical permissions to release. ## How is it done? +### With direct push permissions + +This is the typical way for the core maintainer/benevolent dictator. + The release contains the following steps: 1. Update the CHANGELOG.md and the _version.py via `python make_release.py`. This also prepares the release commit message. 2. Create a release commit: `git commit -eF RELEASE_COMMIT_MSG.md`. -3. Tag that commit: `git tag -s {{version}} -eF RELEASE_TAG_MSG.md`. -4. Push both: `git push && git push --tags`. -5. CI now builds a source and a wheels package which it pushes to PyPI. It also - creates a GitHub release. +3. Push commit: `git push`. +4. CI now builds a source and a wheels package which it pushes to PyPI. It also + creates the corresponding tag and a GitHub release. ![](../_static/releasing.drawio.png) +### Using a Pull Request + +This is the typical way for collaborators which do not have direct push permissions for +the `main` branch. + +The release contains the following steps: + +1. Update the CHANGELOG.md and the _version.py via `python make_release.py`. + This also prepares the release commit message. +2. Push the changes to a dedicated branch. +3. Open a pull request starting with `REL: `, followed by the new version number. +4. Wait for the approval of another eligible maintainer. +5. Merge the pull request with the name being the PR title and the body being + the content of `RELEASE_COMMIT_MSG.md`. +7. CI now builds a source and a wheels package which it pushes to PyPI. It also + creates the corresponding tag and a GitHub release. + ### The Release Tag * Use the release version as the tag name. No need for a leading "v". diff --git a/make_release.py b/make_release.py index 4ec62ed4d..f6d16f0a7 100644 --- a/make_release.py +++ b/make_release.py @@ -49,7 +49,7 @@ def main(changelog_path: str) -> None: new_entry = header + changes + trailer print(new_entry) write_commit_msg_file(new_version, changes_with_author + trailer) - write_release_msg_file(new_version, changes_with_author + trailer, today) + # write_release_msg_file(new_version, changes_with_author + trailer, today) # Make the script idempotent by checking if the new entry is already in the changelog if new_entry in changelog: @@ -69,9 +69,7 @@ def print_instructions(new_version: str) -> None: print("") print("Now run:") print(" git commit -eF RELEASE_COMMIT_MSG.md") - print(f" git tag -s {new_version} -eF RELEASE_TAG_MSG.md") print(" git push") - print(" git push --tags") def adjust_version_py(version: str) -> None: