Releasing a pylint version

So, you want to release the X.Y.Z version of pylint ?

Process

Run the acceptance tests to see if everything is alright with this release. We don't run them on CI: pytest -m acceptance
Check if the dependencies of the package are correct
Update __version__ in pylint/__pkginfo__.py, dev_version should be None when you tag, except if it's an alpha release.
Put the version numbers, and the release date into the changelog
Put the release date into the What's new section.
Generate the new copyright notices for this release:

pip3 install copyrite
copyrite --contribution-threshold 1 --change-threshold 3 --backend-type \
git --aliases=.copyrite_aliases . --jobs=8
# During the commit pre-commit and pyupgrade will remove the encode utf8
# automatically

Submit your changes in a merge request.
Make sure the tests are passing on Travis/GithubActions: https://travis-ci.org/PyCQA/pylint/
Do the actual release by tagging the master with pylint-X.Y.Z (ie pylint-1.6.12 for example). Travis should deal with the release process once the tag is pushed with git push origin --tags
Go to github, click on "Releases" then on the pylint-X.Y.Z tag, choose edit tag, and copy past the changelog in the description.

Manual Release

Following the previous steps, for a manual release run the following commands:

git clean -fdx && find . -name '*.pyc' -delete
python setup.py sdist --formats=gztar bdist_wheel
twine upload dist/*
# don't forget to tag it as well

Post release

New branch to create for major releases

The master branch will have all the new features for the X.Y+1 version

If you're doing a major release, you need to create the X.Y branch where we will cherry-pick bugs to release the X.Y.Z+1 minor versions

Merge tags in master for minor releases

Merge the tag X.Y.Z in the main branch by doing a history only merge. It's done in order to signal that this is an official release tag, and for pre-commit autoupdate to works.

git checkout master
git merge --no-edit --strategy=ours pylint-X.Y.Z
git push

Milestone handling

We move issue that were not done in the next milestone and block release only if it's an issue labelled as blocker.

Files to update after releases

Changelog

Create a new section, with the name of the release X.Y.Z+1 on the X.Y branch.
If it's a major release, also create a new section for X.Y+1.0 on the master branch

You need to add the estimated date when it is going to be published. If no date can be known at that time, we should use Undefined.

Whatsnew

If it's a major release, create a new What's new in Pylint X.Y+1 document Take a look at the examples from doc/whatsnew.

Versions

Update __version__ to X.Y+1.0 in pylint/__pkginfo__.py for master and to X.Y.Z+1 for the X.Y branch. dev_version should also be back to an integer after the tag.

2.9 KiB Raw Blame History