Releasing a pylint version#
So, you want to release the X.Y.Z
version of pylint ?
Releasing a major or minor version#
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
.
Write the
Summary -- Release highlights
indoc/whatsnew
and upgrade the release date.Remove the empty changelog for the last unreleased patch version
X.Y-1.Z'
. (For example:v2.3.5
)Check the result of
git diff vX.Y-1.Z' doc/whatsnew
. (For example:git diff v2.3.4 doc/whatsnew
)Install the release dependencies:
pip3 install -r requirements_test.txt
Bump the version and release by using
tbump X.Y.0 --no-push --no-tag
. (For example:tbump 2.4.0 --no-push --no-tag
)Check the commit created with
git show
amend the commit if required.Create a new
What's new in Pylint X.Y+1
document. Add it todoc/index.rst
. Take a look at the examples fromdoc/whatsnew
. Commit that withgit commit -am "wip"
.Move the
main
branch up to a dev version withtbump
:
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, fixup the 'wip' commit with the what's new then push to a release branch
Open a merge request with the two commits (no one can push directly on
main
)After the merge, recover the merged commits on
main
and tag the first one (the version should beX.Y.Z
) asvX.Y.Z
(For example:v2.4.0
)Push the tag.
Release the version on GitHub with the same name as the tag and copy and paste the appropriate changelog in the description. This triggers the PyPI release.
Delete the
maintenance/X.Y-1.x
branch. (For example:maintenance/2.3.x
)Create a
maintenance/X.Y.x
(For example:maintenance/2.4.x
from thev2.4.0
tag.)Close the current milestone and create the new ones (For example: close
2.4.0
, create2.4.1
and2.6.0
)
Backporting a fix from main
to the maintenance branch#
Whenever a commit on main
should be released in a patch release on the current
maintenance branch we cherry-pick the commit from main
.
During the merge request on
main
, make sure that the changelog is for the patch versionX.Y-1.Z'
. (For example:v2.3.5
)After the PR is merged on
main
cherry-pick the commits on themaintenance/X.Y.x
branch (For example: frommaintenance/2.4.x
cherry-pick a commit frommain
)Remove the "need backport" label from cherry-picked issues
Release a patch version
Releasing a patch version#
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.
Check the result of
git diff vX.Y-1.Z-1 doc/whatsnew
. (For example:git diff v2.3.4 doc/whatsnew
)Install the release dependencies:
pip3 install -r requirements_test.txt
Bump the version and release by using
tbump X.Y-1.Z --no-push
. (For example:tbump 2.3.5 --no-push
)Check the result visually with
git show
.Open a merge request to run the CI tests for this branch
Create and push the tag.
Release the version on GitHub with the same name as the tag and copy and paste the appropriate changelog in the description. This triggers the PyPI release.
Merge the
maintenance/X.Y.x
branch on the main branch. The main branch should have the changelog forX.Y-1.Z+1
(For examplev2.3.6
). This merge is required sopre-commit autoupdate
works for pylint.Fix version conflicts properly, or bump the version to
X.Y.0-devZ
(For example:2.4.0-dev6
) before pushing on the main branchClose the current milestone and create the new one (For example: close
2.3.5
, create2.3.6
)
Milestone handling#
We move issues that were not done to the next milestone and block releases only if there
are any open issues labelled as blocker
.