github/pyenv
1
0
Fork 0
mirror of https://github.com/pyenv/pyenv.git synced 2024-11-14 20:39:55 -05:00
Code Issues Projects Releases Packages Wiki Activity

MAINTENANCE.md: easier way to make a release

Browse source
This commit is contained in:
Ivan Pozdeev 2024-10-28 02:53:18 +03:00
parent 96b3fb2fc3
commit d64d1aa1e0
1 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
MAINTENANCE.md
View file

@ -4,12 +4,14 @@ Creating a release
The release of the new version of Pyenv is done via GitHub Releases. The release of the new version of Pyenv is done via GitHub Releases.
Release checklist: Release checklist:
* Start [drafting a new release on GitHub](https://github.com/pyenv/pyenv/releases) to generate a summary of changes. Save the summary locally. * Start [drafting a new release on GitHub](https://github.com/pyenv/pyenv/releases) to generate a summary of changes.
Type the would-be tag name in the "Choose a tag" field and press "Generate release notes"
* The summary may need editing. E.g. rephrase entries, delete/merge entries that are too minor or irrelevant to the users (e.g. typo fixes, CI) * The summary may need editing. E.g. rephrase entries, delete/merge entries that are too minor or irrelevant to the users (e.g. typo fixes, CI)
* Update `CHANGELOG.md` with the new version number and the edited summary (only the changes section)
* Push the version number in `libexec/pyenv---version` * Push the version number in `libexec/pyenv---version`
* Minor version is pushed if there are significant functional changes (not e.g. bugfixes/formula adaptations/supporting niche use cases). * Minor version is pushed if there are significant functional changes (not e.g. bugfixes/formula adaptations/supporting niche use cases).
* Major version is pushed if there are breaking changes * Major version is pushed if there are breaking changes
* Update `CHANGELOG.md` with the new version number and the edited summary (only the changes section), reformatting it like the rest of the changelog sections
* Commit the changes locally into `master` * Commit the changes locally into `master`
* Create a new tag with the new version number and push the changes including the tag * Create a new tag locally with the same name as specified in the new release window
* Create a new release on GitHub based on the tag, using the saved summary * Push the changes including the tag
* In the still open new release window, press "Publish release". The now-existing tag will be used.