Post pylint 3.0.3

[jacobtylerwalls]

No description provided.

[codecov]

Codecov Report

Merging #9297 (39cfcc8) into main (47410ad) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9297   +/-   ##
=======================================
  Coverage   95.81%   95.81%           
=======================================
  Files         173      173           
  Lines       18767    18767           
=======================================
  Hits        17981    17981           
  Misses        786      786           

[Pierre-Sassoulas]

Shouldn't this be a merge of the maintenance branch containing all the commit from maintenance/3.0.x ?

[jacobtylerwalls]

I rebased them out, was that wrong? I also had to manually delete the change log files.

[Pierre-Sassoulas]

We need to actually merge due to pre-commit autoupdate that do not understand what the latest version is otherwise. (Not much details in the doc but it's here: https://pylint.readthedocs.io/en/stable/development_guide/contributor_guide/release.html#releasing-a-patch-version). There's a lot of small conflicts and subtlety to handle each time, I usually freeze the main branch (do not merge something else in the meantime) and do a git diff origin/main during the mandatory 3 merge conflicts on versions before git merge --continue. It permits to check that the diff to main make sense and have a single merge commit. (Especially since we'll need to merge later so fixup commit would be visible)

[jacobtylerwalls]

Yeah, I did see that in the docs and did want to be conscious of this. What I didn't grok is that (and let me know if I have this right) is that there needs to be a commit before this one on main that sets the 3.0.x patch version). Sounds like this merge request we're discussing now would then have two commits.

If I include all the older commits, which I did in 4255774, you see that the diff is exactly the same after the force-push to ffff974, other than needing to remove the deleted changelog fragments. The "compare" button shows this.

It permits to check that the diff to main make sense and have a single merge commit. (Especially since we'll need to merge later so fixup commit would be visible)

I didn't follow this part; the diff is actually a lot worse if you leave the older commits in. It's confused us before, although I can't find the PR where we discussed it.

[jacobtylerwalls]

We should add an instruction to release.rst to go through and manually delete the changelog fragments. I just started attempting this from scratch and they still weren't picked up when merging maintenance into main.

[jacobtylerwalls]

(I'll do it the classic way in another MR so we can unblock things.)

[Pierre-Sassoulas]

It's voluntary to duplicate the fragment in 3.0.3 and 3.1.0 (Can't find the rational but it was around the time #7362 was opened) #7426 (comment) (edit: but there's no rational)