diff options
author | Pierre Sassoulas <pierre.sassoulas@gmail.com> | 2021-04-26 12:15:15 +0200 |
---|---|---|
committer | Pierre Sassoulas <pierre.sassoulas@gmail.com> | 2021-04-26 17:38:28 +0200 |
commit | c234b3efe19db81d0d03d46c4afa6886129bd25c (patch) | |
tree | a2896426ff36b57a3026855a0a9e7a907c7490da | |
parent | 76a232e0cd3abb0f2d395cd2fe035046daef80fb (diff) | |
download | pylint-git-c234b3efe19db81d0d03d46c4afa6886129bd25c.tar.gz |
Update documentation and changelog
-rw-r--r-- | ChangeLog | 2 | ||||
-rw-r--r-- | doc/release.md | 26 |
2 files changed, 11 insertions, 17 deletions
@@ -13,6 +13,8 @@ Release date: TBA Closes #4405 +* scm_setuptools has been added to the packaging. + What's New in Pylint 2.8.1? =========================== diff --git a/doc/release.md b/doc/release.md index fc0805ead..a9a67260c 100644 --- a/doc/release.md +++ b/doc/release.md @@ -7,11 +7,8 @@ So, you want to release the `X.Y.Z` version of pylint ? 1. Run the acceptance tests to see if everything is alright with this release. We don't run them on CI: `pytest -m acceptance` 2. Check if the dependencies of the package are correct -3. Update `__version__` in `pylint/__pkginfo__.py`, `dev_version` should be `None` when - you tag, except if it's an alpha release. -4. Put the version numbers, and the release date into the changelog -5. Put the release date into the `What's new` section. -6. Generate the new copyright notices for this release: +3. Put the release date into the changelog and `What's new` section. +4. Generate the new copyright notices for this release: ```bash pip3 install copyrite @@ -21,17 +18,17 @@ git --aliases=.copyrite_aliases . --jobs=8 # automatically ``` -7. Submit your changes in a merge request. +5. Submit your changes in a merge request. -8. Make sure the tests are passing on Travis/GithubActions: +6. Make sure the tests are passing on Travis/GithubActions: https://travis-ci.org/PyCQA/pylint/ -9. 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` +7. Do the actual release by tagging the master with `pylint-X.Y.Z` (ie `pylint-1.6.12` + or `pylint-4.0.0a1` for example). Travis should deal with the release process once + the tag is pushed with `git push origin --tags` -10. 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. +8. 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 @@ -77,8 +74,3 @@ known at that time, we should use `Undefined`. 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` or `X.Y.Z+1` in `__pkginfo__`. `dev_version` should -also be back to an integer after the tag. |