New release process #1438

Pierre-Sassoulas · 2022-03-03T16:56:56Z

Description

Type of Changes

	Type
✓	✨ New feature
✓	🔨 Refactoring
✓	📜 Docs

Related Issue

This document the new git flow.

doc/release.md

DanielNoord · 2022-03-04T08:27:01Z

@Pierre-Sassoulas Can I recommend not to create a branch every time but just create a branch from the release commit when needed? This is probably personal preference, but I don't really see the benefit in keeping 10+ unused branches around.

You can just 1) create branch from release commit, 2) cherry-pick relevant hot fixes, 3) release, 4) merge hotfix branch into main (to merge commit history and changelog), 5) drop hot-fix branch.
You could wait with 4 and 5 for a couple of days to wait for any potential new hot fixes of course.

Pierre-Sassoulas · 2022-03-04T09:07:22Z

Thanks for the suggestion I upgraded.

Regarding 4) and 5):

merge hotfix branch into main (to merge commit history and changelog),

I think the changelog will already be in the main branch as all MR are for the main branch. In pylint we'll need to do that because of pre-commit but maybe not for astroid ?

drop hot-fix branch.

I don't know about this one, it's better to keep the historic of release branch if we mess up and need to investigate. Also probably easier than having to recreate branch from tag. (I don't want to have to maintain the n-2 release to be clear, but keeping the branch for a year does not hurt that much.)

DanielNoord · 2022-03-04T09:34:57Z

merge hotfix branch into main (to merge commit history and changelog),

I think the changelog will already be in the main branch as all MR are for the main branch. In pylint we'll need to do that because of pre-commit but maybe not for astroid ?

If we have commits on main for 2.20 there won't be a changelog entry/list for 2.19.1 anymore. If we then need a hotfix for 2.19 and create 2.19.1 we will lose that information if we don't merge the 2.19.1 branch into main.

I don't know about this one, it's better to keep the historic of release branch if we mess up and need to investigate. Also probably easier than having to recreate branch from tag. (I don't want to have to maintain the n-2 release to be clear, but keeping the branch for a year does not hurt that much.)

Hm, okay but perhaps we should then mention that they should be removed after a year? Or after 2.20 is released?

Pierre-Sassoulas · 2022-03-04T10:11:03Z

If we have commits on main for 2.20 there won't be a changelog entry/list for 2.19.1 anymore.

Hmm, right, but it should, so the merge goes well later on. Also because of " Make sure that the changelog is for the patch version X.Y-1.Z'". Let me check the update script then.

Or after 2.20 is released?

Yes it seem sensible. Indicate that we're not maintaining it anymore. At this point the latest tag is keeping the history accessible.

Pierre-Sassoulas · 2022-03-04T19:06:23Z

I think the current script would work, right now for example we have a changelog for 2.10.1 : https://github.com/PyCQA/astroid/blob/main/ChangeLog#L18

I'm going to remove it before releasing for 2.11.0 as it's never going to be released. But it could be used to do hotfix the 2.10 branch. What we also need to do is launch the script to get the changelog for 2.10.2 on the main branch when/if we release 2.10.1.

cdce8p

Some questions

If we cherry-pick a commit, the changelog entry will still be for the next minor release. During the release process, I think the maintainer would need to manually copy the entries to the bug fix release. Maybe with a prefix Backport: ?
When should we stop to backport bug fixes? Once the next minor version is released?
Depending on (2): What should the changelog order be? Currently it's both sorted chronological and by version. If we support multiple minor versions in parallel, it might make sense to drop the version sorting. E.g. 2.10.0 -> 2.11.0 -> 2.10.1 -> 2.10.2
Should a new bug fix release be done for every single cherry-picked commit? Grouping would make sense IMO. Of course only if there are multiple issues that need to be fixed.

cdce8p · 2022-03-04T20:40:41Z

doc/release.md

+- Cherry-pick the version bumping commit on the main branch so the main branch has the
+  changelog for `X.Y-1.Z+1`.


I think it would be better to merge the bug fix branch into main, instead of cherry-picking a single commit.

Hmm, you're right, it also fix the pre-commit issue we have with pylint.

Pierre-Sassoulas · 2022-03-04T21:04:50Z

Right now in astroid we have 2.11.0 and 2.10.1 in the changelog, I'm going to use that example for clarity.

If we cherry-pick a commit, the changelog entry will still be for the next minor release. During the release process, I think the maintainer would need to manually copy the entries to the bug fix release. Maybe with a prefix Backport: ?

If this is something we want to backport in 2.10, we would need to put the changelog in 2.10.1 when we merge the PR in main (and always squash ?). Then we cherry-pick the (squashed) commit on the 2.10 branch. I think it work because if it's in 2.10.1, it's natural that it's in 2.11.0 too and we don't have anything more to do?

When should we stop to backport bug fixes? Once the next minor version is released?

I think it make sense that's what I was thinking of (we also delete the 2.10 branch which makes our intent clear).

Depending on (2): What should the changelog order be? Currently it's both sorted chronological and by version. If we support multiple minor versions in parallel, it might make sense to drop the version sorting. E.g. 2.10.0 -> 2.11.0 -> 2.10.1 -> 2.10.2

I was thinking about semver order, once 2.11 is out we'll never release a 2.10.x again. I did not thing about major version yet. How long are we going to support 2.X in parallel when 3.0.0 is out ?

Should a new bug fix release be done for every single cherry-picked commit? Grouping would make sense IMO. Of course only if there are multiple issues that need to be fixed.

I was thinking of releasing frequently (maybe not each bug fix, but at least each week if something was fixed during the previous week). This is why I did #1441 because it's really taking a long time in the release process and was not acceptable anymore if we release often.

Thank you for reviewing @cdce8p I appreciate that :)

cdce8p · 2022-03-04T21:34:23Z

If this is something we want to backport in 2.10, we would need to put the changelog in 2.10.1 when we merge the PR in main (and always squash ?). Then we cherry-pick the (squashed) commit on the 2.10 branch. I think it work because if it's in 2.10.1, it's natural that it's in 2.11.0 too and we don't have anything more to do?

🤔 So you're basically suggestion adding two changelog entries one for 2.10.1 and one for 2.11.0?
Although that might work, the issue then becomes that the 2.10 branch will contain the 2.11.0 changelog entries too which would need be to removed manually I think.

What if we instead remove the sections for unreleased versions all together and only add them during the release. New changelog entries would only be added once. Cherry-picking a commit with a subsequent release + merge back into main would "double" it. (The last step might create a small merge conflict every time. However it should be fairly easy to resolve as the new release should be below new changes.

When should we stop to backport bug fixes? Once the next minor version is released?

I think it make sense that's what I was thinking of (we also delete the 2.10 branch which makes our intent clear).

👍🏻 Sounds good to me.

Depending on (2): What should the changelog order be? Currently it's both sorted chronological and by version. If we support multiple minor versions in parallel, it might make sense to drop the version sorting. E.g. 2.10.0 -> 2.11.0 -> 2.10.1 -> 2.10.2

I was thinking about semver order, once 2.11 is out we'll never release a 2.10.x again. I did not thing about major version yet. How long are we going to support 2.X in parallel when 3.0.0 is out ?

If we drop the last bug fix branch once the next minor version is release, I don't think this will be an issue anymore.
The move to 3.0.0 is something different, but personally I would strongly prefer not to support multiple major versions at the same time. On the off-chance we do need to do some last fix, we would probably insert it in version order anyway, since the 2.x.x branch wouldn't contain the changelog for 3.x.

Should a new bug fix release be done for every single cherry-picked commit? Grouping would make sense IMO. Of course only if there are multiple issues that need to be fixed.

I was thinking of releasing frequently (maybe not each bug fix, but at least each week if something was fixed during the previous week). This is why I did #1441 because it's really taking a long time in the release process and was not acceptable anymore if we release often.

👍🏻

--
A few additional things.

Do we what to add change categories to the changelog? E.g. Feature, Fix, Deprecation, Breaking. Another example here is could be black: https://github.com/psf/black/blob/main/CHANGES.md
Looking at the black changelog, they do have the Unreleased heading. Maybe that would fit for what I mentioned above.

DanielNoord · 2022-03-04T22:23:11Z

I think one issue we need to tackle is whether we want to merge 2.10.1 into the 2.11 branch before releasing 2.11. Initially I suggested to do so, but I'm thinking that this might be complicate things (a lot).
cpython does not (as far as I can see) and whenever there is a security fix a commit is made on all supported branches. This makes it much easier as you don't have the issue of what to do with the changelog entries of 2.10.1 on the 2.11 branch.

I would suggest the following workflow (but I'd really like input here):

Release 2.10
Bump main to 2.11.0+dev
Create 2.10 branch with bump to 2.10.1+dev
Commit fix to main
Cherry-pick fix commit to 2.10 branch
Release 2.10.1 from 2.10 branch > bump to 2.10.2+dev
...
Drop 2.10 branch
Release 2.11
Repeat step 1.

Basically that would mean that we support every minor version with necessary hot fixes that get cherry picked from main until we release a new minor version, which then becomes the new branch to cherry-pick to.

Pierre-Sassoulas · 2022-03-05T08:21:15Z

So you're basically suggestion adding two changelog entries one for 2.10.1 and one for 2.11.0?

No, only one for 2.10.1. On the main branch we have the changelog for 2.10.1 https://github.com/PyCQA/astroid/blob/main/ChangeLog#L18, we just need to decide if we're going to backport before merging into main so the changelog entry is in the proper section.

What if we instead remove the sections for unreleased versions all together and only add them during the release.

I think it's going to make a lot of work and potential mistake reviewing everything at release time and classifying what goes where. I think it's better if it's done little by little during each merge request.

I would strongly prefer not to support multiple major versions at the same time.

👍 Then it's easier than a minor release version. It make sense too, because there will be breaking change, backporting would be harder.

Do we what to add change categories to the changelog? E.g. Feature, Fix, Deprecation, Breaking. Another example here is could be black: https://github.com/psf/black/blob/main/CHANGES.md
Looking at the black changelog, they do have the Unreleased heading. Maybe that would fit for what I mentioned above.

I like what black is doing. We have another issue we might want to fix at the same time (it's only in pylint but let's discuss it here). We're duplicating the changelog entries between the whatsnew and the changelog file pylint-dev/pylint#5728. This might be the occasion to stop doing that. Maybe creating the whatsnew programmatically from a well organized changelog ? Maybe taking all the handling code from black directly ? (I'd like to do that only after 2.13 is released though, it's a lot of work.)

This makes it much easier as you don't have the issue of what to do with the changelog entries of 2.10.1 on the 2.11 branch.

I think there won't be too much issue as we have only the 2.10 branch (we delete the 2.9 branch) we just need to make sure the changelog entry for the 2.10.2 version end on the main branch when we release 2.10.1.

I adapted a little what you proposed @DanielNoord :

Release 2.10
Bump main to 2.11.0+dev0
Commit fix to main # We create the branch only if there's a fix to backport
Create 2.10 branch with bump to 2.10.1+dev
Cherry-pick fix commit to 2.10 branch
Release 2.10.1 from 2.10 branch
Bump 2.10 branch to 2.10.2+dev
Cherry-pick the bump commits from the 2.10 branch on main
bump the version to 2.11.0-dev1 on main (as the cherry-picked commit above will be versioned 2.10.2-dev0)
amend the cherry-picked commit, and push
...
Release 2.11
Drop 2.10 branch

Repeat step 1.

cdce8p · 2022-03-05T23:29:02Z

Is cherry-picking the bump commits enough for pre-commit autoupdate?

jacobtylerwalls · 2022-03-06T14:08:14Z

Cherry-pick the bump commits from the 2.10 branch on main

Just a question: why do the bump commits need to be forward-ported? Do other projects do that?

Pierre-Sassoulas · 2022-03-06T16:31:18Z

Just a question: why do the bump commits need to be forward-ported? Do other projects do that?

The bump commit contain a change to the release date in the changelog as well as the creation of the new version (and also the change to copyright in files but I expect to remove that in #1441) see here : 07c0f60

So we need to cherry-pick it on main in order to have the changelog header for 2.10.2 on the main branch for easy cherry-picking of fix commit on 2.10 later.

Pierre-Sassoulas · 2022-03-06T16:34:43Z

Is cherry-picking the bump commits enough for pre-commit autoupdate?

Sorry I did not answer earlier because I did not understand the question. pre-commit autoupdate is handled by the pre-commit ci bot every monday. Are you asking if pre-commit run --all-files need to be relaunched after the cherry-pick ? I don't think so but I could check.

jacobtylerwalls · 2022-03-06T16:44:18Z

So we need to cherry-pick it on main in order to have the changelog header for 2.10.2 on the main branch for easy cherry-picking of fix commit on 2.10 later.

I was thinking we could just always have the 2.10.2 header on main. (That's what Django does, for instance, after any release, the next commit on main has stub headers for new versions, including bugfix branches, and when finalizing a release date, that's done on main also.) Then if there's some header that never gets filled in with contents because there's a perfect release, you do a commit to delete it and throw a huge party.

as well as the creation of the new version

I guess I don't understand that part, wouldn't we want to avoid forward-porting changes to __VERSION__?

cdce8p · 2022-03-06T16:46:14Z

Is cherry-picking the bump commits enough for pre-commit autoupdate?

Sorry I did not answer earlier because I did not understand the question. pre-commit autoupdate is handled by the pre-commit ci bot every monday. Are you asking if pre-commit run --all-files need to be relaunched after the cherry-pick ? I don't think so but I could check.

Not exactly. If I remember correctly, we had an issue in pylint a while back that pre-commit autoupdate wasn't working with our "old" release process. pylint-dev/pylint#4245

Pierre-Sassoulas · 2022-03-06T18:01:52Z

Not exactly. If I remember correctly, we had an issue in pylint a while back that pre-commit autoupdate wasn't working with our "old" release process

You're right, we need to merge in pylint for this reason. So we might as well merge for astroid too so process are closer.

I was thinking we could just always have the 2.10.2 header on main.

Nice, that would reduce the merge / rebase conflicts drastically and the number of cherry-pick we need to do. Let's do that. How many patch version should we add ? 5 ?

jacobtylerwalls · 2022-03-06T18:20:07Z

How many patch version should we add ? 5 ?

How about just one at a time?

do backports of hotfixes over a week
finalize release date on main and backport it
publish from the hotfix branch
add a (single) new stub on main and backport it

cdce8p · 2022-03-06T18:40:04Z

How many patch version should we add ? 5 ?

How about just one at a time?

I agree. Anything else would just be confusing.

So we might as well merge for astroid too so process are closer.

I'm not an expert in branching strategies, but wouldn't git merge --no-edit --strategy=ours mean that any changes from the bugfix branch would be ignore. Like the final commit release with changelog change?

Pierre-Sassoulas · 2022-03-06T20:16:05Z

I'm not an expert in branching strategies, but wouldn't git merge --no-edit --strategy=ours mean that any changes from the bugfix branch would be ignore. Like the final commit release with changelog change?

Yes and @jacobtylerwalls suggested to modify the changelog on the main branch so then we cherry-pick on 2.10 and we don't need to cancel the version change so it remove one step 👍 .

Pierre-Sassoulas · 2022-03-06T20:31:31Z

So to sumpup:

Release 2.10
Bump main to 2.11.0+dev0
Commit fix to main
Create 2.10 branch with bump to 2.10.1+dev
Cherry-pick fix commit to 2.10 branch
Apply the changelog script as if we were releasing 2.10.1 on main branch (after a week)
Cherry-pick the changelog commits from the main branch on 2.10
Release 2.10.1 from the 2.10 branch
Bump 2.10 branch to 2.10.2+dev
~~bump the version to 2.11.0-dev1 on main (as the cherry-picked commit above will be versioned 2.10.2-dev0)~~
~~amend the cherry-picked commit, and push~~
git merge --no-edit --strategy=ours 2.10 from the main branch
...
Release 2.11
Drop 2.10 branch

Repeat step 1.

After writing it, I realize it's one step less but it's also not using tbump normally (we have to launch a changelog script without modifying the version when it was encapsulated with tbump previousely). Doing it from the main branch is not the "natural" place to tbump 2.10.1.

I think this would make sense:

Release 2.10
Bump main to 2.11.0+dev0
Commit fix to main # We create the branch only if there's a fix to backport
Create 2.10 branch with bump to 2.10.1+dev
Cherry-pick fix commit to 2.10 branch
Release 2.10.1 from 2.10 branch
Bump 2.10 branch to 2.10.2+dev
git merge 2.10, fix conflict (only on version change imo ?) bump the version to 2.11.0-dev1
push the merge commit
...
Release 2.11
Drop 2.10 branch

DanielNoord · 2022-03-10T21:54:30Z

I've read the doc for numpy release and it's a little different than what we need. They have a lot of maintenance branches when we only support the latest minor. Let's talk about the release note automated generation in more detail for PyCQA/pylint#5728

The only difference (I think) is that we drop the maintenance branch once we release the next minor version. All the stuff about preparing the maintenance branch for future development and merging the changelog changes into main is relevant for us I think.

Pierre-Sassoulas · 2022-03-10T22:01:37Z

All the stuff about preparing the maintenance branch for future development and merging the changelog changes into main is relevant for us I think.

Could you copy paste the relevant part, please ? There's a lot of content, I think I missed it :)

DanielNoord

😅

Perhaps I should just have made a counter-PR.
I think my proposed changes address all points raised so far and are explicit in how to handle everything. Let me know what you think!

doc/release.md

DanielNoord · 2022-03-10T22:08:06Z

doc/release.md

-### Back to a dev version
-
-Move back to a dev version with `tbump`:
+9. Move back to a dev version with `tbump`:


Suggested change

9. Move back to a dev version with `tbump`:

6. Move the `main` branch up to a dev version with `tbump`:

doc/release.md

DanielNoord · 2022-03-10T22:29:43Z

doc/release.md

+13. Merge the `X.Y-1` branch on the main branch. The main branch should have the
+    changelog for `X.Y-1.Z+1`. This merge is required so `pre-commit autoupdate` works
+    for pylint.
+14. Fix version conflicts properly, or bump the version to `X.Y.0-devZ` before pushing
+    on the main branch


Suggested change

13. Merge the `X.Y-1` branch on the main branch. The main branch should have the

changelog for `X.Y-1.Z+1`. This merge is required so `pre-commit autoupdate` works

for pylint.

14. Fix version conflicts properly, or bump the version to `X.Y.0-devZ` before pushing

on the main branch

7. Create a new branch based on the `main` branch.

8. Merge the newly created tag into the branch: `git merge --no-edit --strategy=ours vX.Y-1.Z`. (For example: `git merge --no-edit --strategy=ours v2.4.1`.

9. Merge the changes to changelog, contributors and documentation from the maintenance branch into the branch. **Note: make sure that all changelog entries included in the patch release are removed from the changelog for the in-development version on `main`.**

10. Make a PR from the new branch on `main`.

The last steps are necessary so that `main` has access to the correct tags as well as a consolidated changelog history.

Ha I understand why you don't want to merge the fix branch. You want to remove the patch release note from the main branch ? But we have only one documentation online, we want to have all the release notes on it for all versions in the right version. If we backport fix in the 2.10.x branch the first time something is released will be 2.10.1 or something, but it will also be included in 2.11.0. If we remove those release note it won't be in the release notes at all (the main branch being the source of truth for the online doc). Thus we can simply merge.

I think it will be on main.

What I propose is:

Initial PR targets 2.5.0 changelog
When you open the PR you cannot determine which patch release it will go in, as we are now probably releasing those more often. Therefore, you should just target the in-development version and let the patch version releaser deal with moving the changelog entry

After the cherry-pick, a commit is added that moves the changelog entry from 2.5.0 to 2.4.1

After 2.4.1 is released a post-release PR is made to main which updates changelog, contributors and docs. Thereby also moving the changelog entry from 2.5.0 to 2.4.1 on main.

At the end the changelog entry will thus be in the version that first released it. Doing it this way makes it so that updating the changelog position becomes the responsibility of the patch version releaser (who only has to do it once) instead of the PR opener (who will have to update his PR every time a new patch release is released).
For astroid the difference might be quite low as we don't release patches very often, but for pylint not having to update all PRs after every patch release is quite useful I think.

I see !

I think patch releases would still be "blocked" until we have ~~all~~ most the flying bug/crash PR done so it should not happen very often that you need to rebase and change the location in the changelog. But if it does then we don't need to do it, I'll fix it at release time like I currently do (this is what the git diff changelog v2.4.0 is about, I check that all modification to the changelog are in the proper section). I'd rather have some release note to fix than all release note to fix. Also the decision to backport should be taken in the MR. When we merge the fix branch in main, it will also fix the main branch.

What we can do to make this process easier is to create a "To be backported" section that we then copy pasted later when releasing (Marc talked about that being done in black)

Also the decision to backport should be taken in the MR. When we merge the fix branch in main, it will also fix the main branch.

This is also fine with me, but note that this is a different process than the one we have been discussing so far.

As I interpreted it, we either:
Commit to main, cherry-pick to maintenance, push changelog/doc and the tag to main from maintenance
Or:
Commit to maintenance, merge maintenance in main.

I thought the whole idea was not to merge maintenance into main and only push the tags into main. Otherwise any fix-PR can just target the maintenance branch, as it will eventually end up in main. There is no reason to cherry-pick in that case.

But okay, we have been spending way too much time discussing this and you're likely the one who has to fix any issues that come from this process. I just wanted to highlight (and potentially solve) some future issues that might arise from this not being crystal-clear. As long as you have a clear idea of how you want to approach things I guess it should be fine.

I did not apply the suggestion directly in github because there was a lot to change but I applied it manually.

doc/release.md

Astroid do not have pre-commit

Co-authored-by: Daniël van Noord <[email protected]>

See https://github.com/PyCQA/astroid/pull/1438\#discussion_r823147053

DanielNoord

Thanks @Pierre-Sassoulas! This is becoming much clearer and should be followable for anybody not directly associated with the project.

Some last spelling comments from my end 😄

DanielNoord · 2022-03-12T08:52:22Z

doc/release.md

 ```

 Check the result and then upgrade the main branch

-### Milestone handling
+11. Delete the `maintenance/X.Y-1.x` branch. (For example: `maintenance/2.3.x`)


And create a new ......

DanielNoord · 2022-03-12T08:53:33Z

doc/release.md

+
+1. During the merge request on `main`, make sure that the changelog is for the patch
+   version `X.Y-1.Z'`. (For example: `v2.3.5`)
+2. Create a `maintenance/X.Y.x` branch on Github --if it does not already exist-- from


I think it's good to make the maintenance branch always as it is also a visual pointer about which versions are still supported.

doc/release.md

DanielNoord · 2022-03-12T08:54:13Z

doc/release.md


-## Post release
+4. Check the result of `git diff vX.Y-1.Z-1 ChangeLog`. (For example:


Numbering is incorrect here.

I removed the numbering, it's hard to update and it's ruining the diff for each change :)

DanielNoord · 2022-03-12T08:54:31Z

doc/release.md

+8. Push the tag.
+9. Release the version on GitHub with the same name as the tag and copy and paste the
+   appropriate changelog in the description. This trigger the pypi release.
+10. Move the `main` branch up to a dev version with `tbump`:


Suggested change

10. Move the `main` branch up to a dev version with `tbump`:

10. Move the `maintenance` branch up to a dev version with `tbump`:

Just realized that we definitely don't want to make our life harder by doing that !

Co-authored-by: Daniël van Noord <[email protected]>

doc/release.md

Co-authored-by: Daniël van Noord <[email protected]>

@staticmethod

…ion 2.13.0 Andreas Finkler (1): ``pyreverse``: better error messages for unsupported file formats (#5951) Antonio Quarta (2): Add mermaidjs as format output for pyreverse (#5272) fix deleting files for pyreverse tests (#5476) Arianna (1): Introduce new 'import-private-name' checker (#5610) Arianna Y (2): Update primer package pandas-dev branch to main (#5669) Fix unprotected accesses to parent.name and add tests (#5675) Daniël van Noord (107): Add typing to ``PyLinter.reporter`` (#5325) Move tests for Google docstrings from ``TestParamDocChecker`` to functional tests (#5484) Move some of the Numpy tests out of ``TestParamDocChecker`` (#5492) Fix incorrect classification of property docstrings in Numpy-style (#5498) Move ``Numpy`` tests from ``TestParamDocChecker`` to functional tests (#5507) Move tests from ``TestParamDocChecker`` to functional tests (#5509) Add a DeprecationWarning to set_config_directly (#5511) Unify validation of functional test option files (#5510) Remove redundant tests in ``TestWhileUsed`` (#5518) Move tests from ``TestComparison`` to functional tests (#5520) Move tests from ``TestConfusingConsecutiveElifChecker`` to functional tests (#5517) Check `node` location attributes in unittests and update tests (#5383) Update typing of reporter attributes in ``PyLinter`` (#5525) Add ``future=True`` to all ``NodeNG.statement()`` calls (#5310) Fix ``not-callable`` for attributes that alias ``NamedTuple`` (#5537) Add regression test for issue #5382 (#5550) Fix crash on uninferable decorators on Python 3.6 and 3.7 (#5549) Add typing to ``_determine_callable`` (#5548) Fixed extremely long processing of long lines with comma's (#5534) Remove unnecessary `if` statement in variable consumption checker (#5531) Fix ``used-before-assignment`` for conditional self-referential typing (#5532) Check if decorator returns use keyword (``unexpected-keyword-arg``) (#5547) Add requirement files to list of files to run primer against (#5566) Add missing settings to pylintrc (#5556) Add typing to some functions in ``testutils`` (#5573) Fix ``used-before-assignment`` for assignment expressions in lambda (#5530) Add typing to file visiting attributes of ``PyLinter`` (#5576) Add typing to checker and plugin attributes of ``PyLinter`` (#5574) Rename ``init_linter`` fixture to ``initialized_linter``, add filename (#5581) Add types to option attributes of ``PyLinter`` and reorganize ``init`` (#5579) Create ``_config_initialization`` util and use in functional tests (#5591) Add documentation about profiling and performance analysis (#5597) Refactor message disabling and enabling (#5596) Make functional tests always go through config initialization (#5594) Update CACHE_VERSION of primer, add comment and update paths (#5611) Use ``dill`` to pickle when run in parallel mode (#5609) Use ``with`` statement in ``parallel.py`` (#5612) Allow passing arguments when entry points are used as functions (#5613) Rename ``arguments`` to ``argv`` in entry point functions (#5619) Allow passing arguments if ``epylint`` entry point is used as function (#5616) Add regression test for issue 5461 (#5623) Remove unnecessary checks for node attributes in ``add_message`` (#5622) Add ``pydocstringformatter`` to pre-commit config Format docstrings with ``pydocstringformatter`` Update astroid to ``2.9.2`` (#5634) Move ``HUMAN_READABLE_TYPES`` to ``constants`` (#5642) Add test for exclusivity of id names (#5615) Rename CI job names (#5618) Fix crash with slots and annotated assignments (#5494) Add ``future=True`` to all ``NodeNG.frame`` calls (#5621) Make sure to split non-separated csv ``OuputLine's`` (#5665) Remove ``lru_cache`` from ``get_active_msgids`` (#5672) Fix crash on properties & inherited methods in ``implicit-booleaness`` (#5652) Add ``lru-cache-decorating-method`` checker (#5674) Add typing to `ScopeConsumer` (#5680) Add typing to ``get_next_to_consume`` and ``_check_consumer`` (#5681) Follow-up to some test changes (#5685) Allow dev version of next minor ``astroid`` version (#5689) Fix ``super-init-not-called`` if parent or ``self`` is a ``Protocol`` (#5697) Fix false positive ``super-init-not-called`` for inherited ``init`` (#5698) Remove the ``check_docs`` extension and remove any references to it (#5730) Add ``DeprecationWarning`` for non-string ``current_name`` & ``file`` (#5580) Create separate documentation page for each message (#5396) Emit the crash issue template for more exceptions and crashes (#5743) Remove unnecessary ``try...except`` from ``frame()`` call (#5664) Fix duplicate names of ``Pylint Messages`` in docs (#5744) Fix remaining typing issues for ``PyLinter`` and related functions (#5663) Add parameter typing to ``PyLinter`` (#5781) Update ``pydocstringformatter`` to 0.4.0 (#5787) Move functional test files to new structure Check functional test directory for correct structure Update Testing docs to reflect enforced folder structure (#5792) Make ``lru-cache-decorating-method`` look for ``maxsize`` argument (#5791) Remove erroneously added ``diofant`` submodule Don't assume test runners have more than 2 cores available Don't assume runners have more than 2 cores available for benchmarking Revert "Increase timeouts" for CI (#5828) Add some flags showing information to the CI pytest runs (#5841) Allow disabling ``duplicate-code`` with a disable comment (#5446) Also test on PyPy 3.7 Use the ``tomli`` package instead of ``toml`` to parse ``.toml`` (#5887) Add ``typevar-name-missing-variance`` checker (#5825) Upgrade mypy to 0.940 (#5900) Update ``astroid`` requirement to 2.11.0 Fixes for tests due to new ``tolineno`` behaviour Add regression test for issue #5408 (#5795) Add tests for #4826 (#5696) Add regression test for #5679 (#5725) Use ``node.position`` in ``add_message`` if available (#5897) Fix end position in unittests (#5904) Fix disabling of ``ungrouped-imports`` (#5903) Use ``functools.cached_property`` on 3.8+ (#5907) Upgrade ``pydocstringformatter`` to ``0.5.0`` (#5910) Fix typing of safe_infer (#5902) Simplify ``cached_property`` import guards (#5915) Update ``pydocstringformatter`` to ``0.5.3`` (#5918) Remove uses of ``NodeNG.doc`` in favour of ``doc_node`` Handle ``ComprehensionScope`` and their behaviour better (#5923) Set up system of code examples and details for message documentation (#5934) Add bad-open-mode and unspecified-encoding documentation (#5954) Add CI test for message documentation (#5956) Add documentation for access-member-before-definition (#5958) Make ``arguments-differ`` check extra parameters for default values (#5539) Create a ``TypeVar`` style for ``invalid-name`` (#5894) Add documentation for abstract-method and abstract-class-instantiated (#5957) Add documentation for messages with anomalous in their name Add documentation for messages with assert in their name (#5960) Jacob Walls (50): Fix #5371: Correctly count arguments to static methods missing @staticmethod decorator (#5412) Add tempfile.TemporaryFile to CALLS_RETURNING_CONTEXT_MANAGERS Fix #4761: Emit `used-before-assignment` where single assignment only made in except blocks (#5402) Fix #5504: Fix crash if the output of items() is assigned to a 1-tuple (#5505) Emit `used-before-assignment` in final or except blocks where try statements could have failed (#5384) Fix false-positive 'used-before-assignment' for assignments in except blocks following try blocks that return (#5506) Fix #3675: `safe_infer()` finds ambiguity among function definitions when number of arguments differ (#5409) Produce a score of 0 for fatal errors and add fatal to score evaluation (#5521) Factor out `_uncertain_nodes_in_except_blocks()` (#5541) Update default evaluation formula to match that in default pylintrc (#5553) Fix #5557: Don't emit `comparison-with-callable` if the callable raises (#5563) Fix #2399: Avoid negative scores by default (#5595) Fix #5370: Emit `redefined-outer-name` when a nested except handler shadows an outer one (#5630) Fix typos in pylint/checkers/variables.py (#5639) Fix #5638: Allow for encoding to be supplied as a positional argument (#5641) Diff generated by python test_functional.py --update-functional-output (#5660) Don't assume direct parentage when emitting `used-before-assignment` (#5582) Fix false positive for `unused-variable` for a comprehension variable matching a type annotation (#5651) Fix #5569: Fix a crash in `unused-private-member` when `type(self)` used in bound methods (#5662) Fix #5586: False positive for `used-before-assignment` with homonyms in filtered comprehensions and except blocks (#5666) Fix false negative for `used-before-assignment` when an Except intervenes between Try/Finally (#5583) Fix typing of get_node_first_ancestor_of_type() and related method (#5686) Fix #5568: Allow nested classes as return annotations (#5688) Fix false negative for `undefined-variable` (#5711) Fix #5713: Emit `used-before-assignment` instead of `undefined-variable` when accessing unused type annotations (#5718) Fix test conflicts after merging two valid MR incompatible together (#5726) Add confidence level `CONTROL_FLOW` (#5709) Fix #5683: False positive ``used-before-assignment`` in loop `else` where the only non-break exit is via `except` (#5684) Fix crash when providing None to mode arg of open() (#5732) Fix typos in unit test docstrings (#5739) Improved `bad-open-mode` message when providing ``None`` to the ``mode`` argument of an `open()` call (#5742) Correct reference to `argv` in documentation for `run_pylint()` (#5741) Fix #5399: Fix false negatives for further variable messages for invalid type annotations or default arguments (#5727) Remove moot TODO (#5747) Remove VariableVisitConsumerAction.CONSUME (#5745) Fix false positive `used-before-assignment` for named expressions in ternary operators (#5748) Fix crash in `use-maxsplit-arg` checker where `sep` given by keyword (#5772) Fix false negative for `used-before-assignment` when some except handlers don't define a name (#5764) Fix `used-before-assignment` false positive for except handler names shared by comprehension test (#5818) Fix #5112: Prevent `used-before-assignment` if named expression found first in container (#5812) Add stdlib xml.etree.cElementTree to deprecated modules (#5863) Removed unused detection of site-packages directory (#5874) Add `distutils` to deprecated modules (#5864) Fix typo in ColorizedTextReporter deprecation warning Correct type annotation of ImportsChecker.dependencies_stat Prevent `useless-suppression` on disables for stdlib deprecation checker (#5876) Fix false positive for `invalid-class-object` when inference fails (#5901) Add regression test for #5771 (#5908) Add regression test for #5770 (#5846) Fix #4590: `used-before-assignment` false positive for class definition in function scope (#5937) Jake Lishman (1): Fix assigning-non-slot false positive with setattr (#5457) Joe Young (1): Add missing __magic__ methods to `_SPECIAL_METHODS_PARAMS` (#5941) Joseph Young (1): Update "How to Write a Checker" docs (#5939) Jérome Perrin (1): typecheck: simplify variadic positional detection (#5417) Kian Meng, Ang (1): Fix typos over the whole codebase (#5540) Konrad Weihmann (1): Allow mccabe 0.7.x (#5896) Kound (2): Improve non ascii checker (#5643) Add a checker for misleading unicode (#5311) Kurian Benoy (1): Add note on how to share the badge for pylint (#5820) Marc Mueller (14): Revert renaming extension tests (#5473) Add additional test cases used-before-assignment with try-except (#5523) Upgrade mypy to 0.920 (#5535) Upgrade mypy to 0.930 (#5592) Bump ci cache version (#5602) Add timeouts for CI jobs (#5752) Improve error message arguments formatting [redefined-slots] (#5754) Increase timeouts (#5755) Upgrade flake8-typing-import to 1.12.0 [pre-commit] (#5760) Fix unsafe utils.safe_infer (#5775) Improve CI workflow (#5868) Add broken NoReturn check (#5304) Add broken Callable check (#5891) Add confidence value to typing extension messages (#5892) Mark Byrne (7): Treat `typing.NamedTuple` self as a sequence (#5346) New checker - Detect use of unnecessary ellipsis (#5470) Fixed false positive for ``global-variable-not-assigned`` when the `del` statement is used (#5656) Add checker `redefined-slots-in-subclass` (#5640) Fixed false positive for ``global-variable-undefined`` (#5690) ``unused-variable`` when `nonlocal` name in a multiple-assignment (#5700) Fix a false negative with tuple unpacking (#5708) Matus Valo (1): Lint all files in a directory by expanding arguments (#5682) Peter Bittner (1): Fix English punctuation and grammar (FAQs) Pierre Sassoulas (72): Upgrade the version to 2.13.0-dev0 following 2.12.2 release Add a path argument to get_tests for functional tests Rename get_tests to get_functional_test_files_from_directory Move the filter for isort 5 out of the generic function Remove a constant that was never used anywhere Deprecate some file in pylint/testutils and update changelog Move the function go retrieve test file to pylint.testutil.functional Move LintModuleOutputUpdate to pylint.testutil.functional Add unit tests for LintModuleOutputUpdate Add a warning in functional test update for bad python versions Add typing to LintModuleOutputUpdate._check_output_text Style - Remove unrelated error in tests for unnecessary-dict-index-lookup Add Confidences in pylint.interfaces API Fix typo in pylint/interfaces.py Fix the typing of pylint.interfaces.implements Modify the description of HIGH confidence for accuracy [refactor] Create a package in order to be able to burst classes.py Style following review: better docstring [refactor] Create a file for the SpecialMethodsChecker in pylint.classes [refactor] Create a file for the ClassChecker in pylint.classes Ignore files with name that starts like an emacs lock files (#5554) Fix unexpected types used in 'get_global_option' (#5555) Revert "Update tbump requirement from ~=6.6.0 to ~=6.6.1 (#5561)" (#5567) Fix some typoes before adding typing for checker registering Fix the typing for BroadTryClause.visit_tryexcept Remove unneccessary use of parenthesis in add_message Add missing method to ``_ManHelpFormatter`` (#5577) Fix typos accross the whole codebase (#5575) Add a code of conduct from template (#5589) Add typing and uniformize the checker registering in Pylinter (#5558) Get the msgid directly from the MessageIdStore (#5606) Add caching to bottlenecks in the message store (#5605) Upgrade astroid to 2.9.1 [regression test] Add functional test for symlinked modules Fix a typo in pylint/typing.py Add a regression test for pylint #73 Clearer error message for useless-else-x type messages (#5736) Fix the period added in docstring automatically by mistake (#5790) Add title in running pylint's documentation (#5837) Add a test to check that no old msgid or symbol are used (#5839) Add a testutil extra-require and add gitpython to it (#5842) Restore the useful part of the python3 checker (#5843) Create a maintener section in contributors.txt and cleanup Remove superfluous role for contributors in contributors.txt Remove superfluous role 'committer' in contributors.txt Upgrade developments guides for CONTRIBUTORS.txt Uniformize formatting in CONTRIBUTORS.txt Enforce one name per line and no line break in CONTRIBUTORS.txt Migrate current copyrite configuration to new format Sort the copyrite aliases alphabetically Add a script to update the CONTRIBUTORS.txt Add more aliases to the contributors.txt configuration Add the email when easily available Separate contributors without email from others Sort contributors according to their number of commits Cleanup after finding emails and duplicates Simplify hard to maintain copyright notice Add a pre-commit hook to check the copyright notice Upgrade documentation for contributors.txt Use the new process created in pylint-dev/astroid#1438 Adaptation for pylint Fix copyright in doc/test_messages_documentation.py [refactor] Create a package in order to be able to burst base.py [refactor] Create a file for _BasicChecker in pylint.checkers [refactor] Create files for comparison checker in pylint.checker.base [refactor] Create a file for the PassChecker in pylint.checker.base [refactor] Create a file for the DocstringChecker in pylint.checker.base [refactor] Create a package for the NameChecker in pylint.checker.base [refactor] Create a file for the BasicErrorChecker in pylint.checker.base [refactor] Create a file for the BasicChecker in pylint.checker.base [cleanup] Remove unused code in pylint.checker.base following refactor Bump pylint to 2.13.0, update changelog Robin Tweedie (1): Document the fact that wrong-import-position is equivalent to pycodestyle E402 (#5774) Sergey B Kirpichev (2): Optimize handling of long lines for checkers like 'missing-final-newline' (#5925) Use pytest-timeout for tests Tim Martin (1): Use value directly instead of index in ``enumerate`` contexts (#5856) Tushar Sadhwani (3): Fix reported node for `unnecessary-comprehension` (#5601) Fix false positive `consider-using-dict-comprehension` when creating a dict using a list of tuple where key AND value vary depending on the same condition (#5590) Avoid using get on a defaultdict (#5766) Téo Bouvard (5): Fix Markdown link in ReStructuredText README (#5870) Fix pre-commit configuration hook URL (#5869) Fix pyreverse type hinting for class methods (#5881) Remove primer test on black-primer (#5924) Fix pyreverse type hints for methods returning None (#5916) dbrookman (1): Fix matching note tags with a non-word char last (#5859) dependabot[bot] (26): Update pre-commit requirement from ~=2.15 to ~=2.16 (#5482) Bump black from 21.11b1 to 21.12b0 (#5481) Bump actions/upload-artifact from 2.2.4 to 2.3.0 Bump actions/download-artifact from 2.0.10 to 2.1.0 Update pytest-xdist requirement from ~=2.4 to ~=2.5 Bump actions/upload-artifact from 2.3.0 to 2.3.1 (#5559) Bump sphinx from 4.3.1 to 4.3.2 (#5560) Update tbump requirement from ~=6.6.0 to ~=6.6.1 (#5561) Bump flake8-typing-imports from 1.11.0 to 1.12.0 (#5562) Bump types-toml from 0.10.1 to 0.10.3 (#5657) Bump mypy from 0.930 to 0.931 (#5659) Bump astroid from 2.9.2 to 2.9.3 (#5658) Bump sphinx from 4.3.2 to 4.4.0 (#5692) Bump python-docs-theme from 2021.11.1 to 2022.1 (#5691) Update pre-commit requirement from ~=2.16 to ~=2.17 (#5710) Bump black from 21.12b0 to 22.1.0 (#5750) Bump actions/setup-python from 2.3.1 to 2.3.2 (#5777) Update pytest requirement from ~=6.2 to ~=7.0 (#5778) Bump types-toml from 0.10.3 to 0.10.4 (#5805) Bump actions/setup-python from 2.3.2 to 3 (#5849) Bump actions/download-artifact from 2.1.0 to 3 (#5865) Bump actions/checkout from 2.4.0 to 3.0.0 (#5866) Bump actions/upload-artifact from 2.3.1 to 3.0.0 (#5867) Update typing-extensions requirement from ~=4.0 to ~=4.1 Bump mypy from 0.940 to 0.941 (#5945) Bump actions/cache from 2.1.7 to 3 (#5944) kasium (2): Enable missing-raises-doc to understand class hierarchies (#5278) Disable bad-docstring-quotes for <= 3.7 (#5526) oittaa (1): Docker: Python 3.10 and Alpine 3.15 (#5443) orSolocate (5): Hotfix mypy pre-commit check under Windows (#5632) Add Or Bahari copyrite aliases (#5721) Add `iterating-modified-list` checker for modified lists (#5628) Add pip install -e to docs before testing (#5687) Fix assignment-from-none false negative case using list.sort() (#5738) pre-commit-ci[bot] (7): [pre-commit.ci] pre-commit autoupdate (#5487) [pre-commit.ci] pre-commit autoupdate (#5603) [pre-commit.ci] pre-commit autoupdate (#5633) [pre-commit.ci] pre-commit autoupdate (#5661) [pre-commit.ci] pre-commit autoupdate (#5758) [pre-commit.ci] pre-commit autoupdate (#5917) [pre-commit.ci] pre-commit autoupdate (#5949) yushao2 (2): fix(4716): fix false positive `unnecessary_dict_index_lookup` emitted when `del` is used (#5344) fix(4756): fix false positive `unused-private-member` for private methods (#5345)

Pierre-Sassoulas added Documentation 📗 Maintenance Discussion or action around maintaining astroid or the dev workflow labels Mar 3, 2022

Pierre-Sassoulas added this to the 2.11.0 milestone Mar 3, 2022

DanielNoord self-requested a review March 3, 2022 17:51

Pierre-Sassoulas force-pushed the new-release-process branch 3 times, most recently from 1618feb to 88d4bf7 Compare March 3, 2022 18:23

Pierre-Sassoulas commented Mar 4, 2022

View reviewed changes

doc/release.md Outdated Show resolved Hide resolved

Pierre-Sassoulas force-pushed the new-release-process branch from d153cdd to 3a3461f Compare March 4, 2022 08:25

cdce8p requested changes Mar 4, 2022

View reviewed changes

DanielNoord reviewed Mar 10, 2022

View reviewed changes

Pierre-Sassoulas and others added 12 commits March 12, 2022 08:46

Document the backporting of bug fixes

b8edcfe

Remove useless precision for pre-commit

890756a

Astroid do not have pre-commit

Review

feed8c4

Add documentation for when we delete maintenance branch

c4b9c48

Add two steps to have proper changelog on all branches

ea7a091

Move the hotfix optional action on the hotfix release doc

fd41a1b

Fix processus following discussion

64e2cd3

Update doc/release.md

c69f558

Co-authored-by: Daniël van Noord <[email protected]>

Specify release order

e4a5cf2

See https://github.com/PyCQA/astroid/pull/1438\#discussion_r823147053

Separate patch version and minor version release

eb6ea2b

Add normalization in tbump

0019fc3

Apply Daniel's review

9a8d6fb

Pierre-Sassoulas force-pushed the new-release-process branch from 78f8ad6 to 9a8d6fb Compare March 12, 2022 08:42

Fix a typo

58d4a8c

DanielNoord requested changes Mar 12, 2022

View reviewed changes

Pierre-Sassoulas and others added 4 commits March 12, 2022 09:55

Remove numbering so the diff is manageable and the doc easier to update

6daa1de

Create maintenance branch all the time

f594919

Update doc/release.md

88e0707

Co-authored-by: Daniël van Noord <[email protected]>

No dev version changes on maintenance branch

993e50f

DanielNoord approved these changes Mar 12, 2022

View reviewed changes

doc/release.md Outdated Show resolved Hide resolved

doc/release.md Outdated Show resolved Hide resolved

doc/release.md Outdated Show resolved Hide resolved

Apply suggestions from code review

df25a0a

Co-authored-by: Daniël van Noord <[email protected]>

Pierre-Sassoulas merged commit 58e1976 into main Mar 12, 2022

Pierre-Sassoulas deleted the new-release-process branch March 12, 2022 09:26

Pierre-Sassoulas added a commit to pylint-dev/pylint that referenced this pull request Mar 24, 2022

Use the new process created in pylint-dev/astroid#1438

027753d

Pierre-Sassoulas added a commit to pylint-dev/pylint that referenced this pull request Mar 24, 2022

Use the new process created in pylint-dev/astroid#1438

547c817

Pierre-Sassoulas added a commit to pylint-dev/pylint that referenced this pull request Mar 24, 2022

Use the new process created in pylint-dev/astroid#1438

2b6184b

		- Cherry-pick the version bumping commit on the main branch so the main branch has the
		changelog for `X.Y-1.Z+1`.

	9. Move back to a dev version with `tbump`:
	6. Move the `main` branch up to a dev version with `tbump`:


		## Post release
		4. Check the result of `git diff vX.Y-1.Z-1 ChangeLog`. (For example:

	10. Move the `main` branch up to a dev version with `tbump`:
	10. Move the `maintenance` branch up to a dev version with `tbump`:

New release process #1438

New release process #1438

Conversation

Pierre-Sassoulas commented Mar 3, 2022 • edited Loading

Description

Type of Changes

Related Issue

DanielNoord commented Mar 4, 2022

Pierre-Sassoulas commented Mar 4, 2022

DanielNoord commented Mar 4, 2022

Pierre-Sassoulas commented Mar 4, 2022

Pierre-Sassoulas commented Mar 4, 2022

cdce8p left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Pierre-Sassoulas commented Mar 4, 2022 • edited Loading

cdce8p commented Mar 4, 2022

DanielNoord commented Mar 4, 2022

Pierre-Sassoulas commented Mar 5, 2022 • edited Loading

cdce8p commented Mar 5, 2022

jacobtylerwalls commented Mar 6, 2022 • edited Loading

Pierre-Sassoulas commented Mar 6, 2022

Pierre-Sassoulas commented Mar 6, 2022

jacobtylerwalls commented Mar 6, 2022

cdce8p commented Mar 6, 2022

Pierre-Sassoulas commented Mar 6, 2022

jacobtylerwalls commented Mar 6, 2022

cdce8p commented Mar 6, 2022

Pierre-Sassoulas commented Mar 6, 2022

Pierre-Sassoulas commented Mar 6, 2022

DanielNoord commented Mar 10, 2022

Pierre-Sassoulas commented Mar 10, 2022

DanielNoord left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielNoord Mar 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielNoord left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Pierre-Sassoulas commented Mar 3, 2022 •

edited

Loading

Pierre-Sassoulas commented Mar 4, 2022 •

edited

Loading

Pierre-Sassoulas commented Mar 5, 2022 •

edited

Loading

jacobtylerwalls commented Mar 6, 2022 •

edited

Loading

DanielNoord Mar 11, 2022 •

edited

Loading