mirror of
https://fuchsia.googlesource.com/third_party/github.com/pylint-dev/pylint
synced 2024-09-22 00:24:37 +00:00
49 lines
1.6 KiB
Plaintext
49 lines
1.6 KiB
Plaintext
Release Process
|
|
===============
|
|
|
|
Pre-developing
|
|
--------------
|
|
|
|
|
|
1. create a new section in the ChangeLog, with the name of the
|
|
release and the estimated date when it is going to be published.
|
|
If no date can be known at that time, we should use ``Undefined``.
|
|
|
|
2. create a new ``What's new in Pylint X.Y`` document. Take a look
|
|
at the examples from doc/whatsnew.
|
|
|
|
|
|
Release process
|
|
---------------
|
|
|
|
1. Preparation
|
|
0. Run the acceptance tests to see if everything is alright with this release.
|
|
We don't run them on CI:
|
|
|
|
pytest -m acceptance
|
|
|
|
1. Check if the dependencies of the package are correct
|
|
2. Update the version number in __pkginfo__
|
|
3. Put the version number and the release date into the changelog
|
|
4. Put the release date into the ``What's new`` section.
|
|
5. If releasing a major or minor version, generate the new copyright notices for this release:
|
|
$ copyrite --contribution-threshold 1 --change-threshold 3 --backend-type git --aliases=.copyrite_aliases . --jobs=8
|
|
|
|
6. Submit your changes.
|
|
|
|
2. Make sure the tests are passing on Travis:
|
|
https://travis-ci.org/PyCQA/pylint/
|
|
|
|
3. Do the actual release by tagging the master with 'pylint-$VERSION'. Travis should deal
|
|
with the release process once the tag is pushed with `git push origin --tags`
|
|
|
|
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
|