So, you want to release the X.Y.Z
version of astroid ?
Before releasing a major or minor version check if there are any unreleased commits on the maintenance branch. If so, release a last patch release first. See Releasing a patch version
.
X.Y-1.Z'
. (For example: v2.3.5
)git diff vX.Y-1.Z' ChangeLog
. (For example: git diff v2.3.4 ChangeLog
)pip3 install -r requirements_minimal.txt
tbump X.Y.0 --no-push --no-tag
. (For example: tbump 2.4.0 --no-push --no-tag
)git show
amend the commit if required.main
branch up to a dev version with tbump
:tbump X.Y+1.0-dev0 --no-tag --no-push # You can interrupt after the first step git commit -am "Upgrade the version to x.y+1.0-dev0 following x.y.0 release"
For example:
tbump 2.5.0-dev0 --no-tag --no-push git commit -am "Upgrade the version to 2.5.0-dev0 following 2.4.0 release"
Check the commit and then push to a release branch
main
)main
and tag the first one (the version should be X.Y.Z
) as vX.Y.Z
(For example: v2.4.0
)maintenance/X.Y-1.x
branch. (For example: maintenance/2.3.x
)maintenance/X.Y.x
(For example: maintenance/2.4.x
from the v2.4.0
tag.) based on the tag from the release. The maintenance branch are protected you won't be able to fix it after the fact if you create it from main.main
to the maintenance branchWhenever a PR on main
should be released in a patch release on the current maintenance branch:
backport maintenance/X.Y-1.x
. (For example backport maintenance/2.3.x
)Needs backport
label and do it manually.We release patch versions when a crash or a bug is fixed on the main branch and has been cherry-picked on the maintenance branch. Below, we will be releasing X.Y-1.Z (where X.Y is the version under development on main
.)
release/X.Y-1.Z
off of maintenance/X.Y.x
git diff vX.Y-1.Z-1 ChangeLog
. (For example: git diff v2.3.4 ChangeLog
)pip3 install -r requirements_minimal.txt
tbump X.Y-1.Z --no-tag --no-push
. (For example: tbump 2.3.5 --no-tag --no-push
. We're not ready to tag before code review.)git show
.maintenance/X.Y-1.x
to run the CI tests for this branch.maintenance/X.Y.x
and fast-forward to the new commit.git tag vX.Y-1.Z
&& git push --tags
post-X.Y-1.Z
from main
.git merge maintenance/X.Y-1.x
: this should have the changelog for X.Y-1.Z+1
(For example v2.3.6
). This merge is required so pre-commit autoupdate
works for pylint.X.Y.0-devZ
(For example: 2.4.0-dev6
).We move issues that were not done to the next milestone and block releases only if there are any open issues labelled as blocker
.