Release 2.15.5 #7660

cdce8p · 2022-10-21T16:00:38Z

Description

My first try doing a release 😄

Cherry-picking worked fine. Ran into a few issues with the contributors-txt script and towncrier though.

Running python3 script/create_contributor_list.py only adds new contributors to the bottom. Is that correct, are they ordered somehow?
Should we add aliases even if they only have one email?
python3 script/bump_changelog.py {new_version} changes the version in towncrier.toml. Should they be reset? I saw that this wasn't included in previous patch releases.
https://github.com/PyCQA/pylint/blob/f324be7de7dd20ac7763954d98d831140c6d5a91/towncrier.toml#L2-L4

Which command do you use to merge the changes into main afterwards? Just git merge upstream/maintenance/2.15.x or something else?

…#7604)

…values inferred (pylint-dev#7627) Add a keyword-only `compare_constants` argument to `safe_infer`.

When the dictionary has served its purpose (making plugin loading pre-and-post init a consistent behaviour), we swap it for bools indicating whether or not a module was loaded. We don't currently use the bools, but it seemed a sensible choice. The main idea is to make the dictionary fully pickle-able, so that when dill pickles the linter for multiprocessing, it doesn't crash horribly. Co-authored-by: Daniël van Noord <13665637+DanielNoord@users.noreply.github.com> Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>

Pierre-Sassoulas · 2022-10-21T16:06:52Z

Running python3 script/create_contributor_list.py only adds new contributors to the bottom. Is that correct, are they ordered somehow?

The script is not doing it properly, I've been manually sorting contributors. tbh I did not find the time to fix it but someone else making the release and having to do the manual sort make the shame sting a little now. If we want to fix this it might be easier to move the additional descriptions to json and then recreate the full file from scratch instead of parsing it each time.

Should we add aliases even if they only have one email?

No we don't have too, only if there's duplicate and an error during generation. (i.e. two emails for one person)

Should they be reset? I saw that this wasn't included in previous patch releases.

I don't really know so I deselected this change because it's less thing to care about when merging the maintenance branch in main later (otherwise we need to revert it manually).

Pierre-Sassoulas · 2022-10-21T16:10:47Z

Which command do you use to merge the changes into main afterwards? Just git merge upstream/maintenance/2.15.x or something else?

This command but things you also need to know:

the changelog is duplicated silently so in astroid you need to check the changelog for the next patch version
It's probably possible to fix conflict with a git checkout --ours but I feel the risk / reward ratio is really too high so I just fix conflict manually
I check the diff with git diff upstream/main before opening a PR (for pylint) or pushing (for astroid) the merge commit to main.

cdce8p · 2022-10-21T16:22:44Z

Which command do you use to merge the changes into main afterwards? Just git merge upstream/maintenance/2.15.x or something else?

This command but things you also need to know:

the changelog is duplicated silently so in astroid you need to check the changelog for the next patch version

It's probably possible to fix conflict with a git checkout --ours but I feel the risk / reward ratio is really too high so I just fix conflict manually

I check the diff with git diff upstream/main before opening a PR (for pylint) or pushing (for astroid) the merge commit to main.

👍🏻 I just tested the merging and it seem to work. At least the final diff is as expected. Had to resolve a few conflicts but was fairly strait forward.

Should they be reset? I saw that this wasn't included in previous patch releases.

I don't really know so I deselected this change because it's less thing to care about when merging the maintenance branch in main later (otherwise we need to revert it manually).

Having tested the back-merge, I think it's safe to include the change (in the maintenance branch). It will be resolved during the merge and even if not updated when the bump_changelog.py script is run.

Running python3 script/create_contributor_list.py only adds new contributors to the bottom. Is that correct, are they ordered somehow?

The script is not doing it properly, I've been manually sorting contributors. tbh I did not find the time to fix it but someone else making the release and having to do the manual sort make the shame sting a little now. If we want to fix this it might be easier to move the additional descriptions to json and then recreate the full file from scratch instead of parsing it each time.

It fine. We can add it to our long ToDo list 😄 I was just confused why it wasn't working / if it was working correctly since I didn't follow the discussions around it.

--

I think the release is ready then.

Pierre-Sassoulas

Just FYI Daniel suggested to create a backporting merge request and then a subsequent release branch to be able to review the release easily, let's do it next time :)

Pierre-Sassoulas · 2022-10-21T17:58:32Z

doc/whatsnew/2/2.15/index.rst

+
+- Sort ``--generated-rcfile`` output.
+
+  Refs #7655 (`#7655 <https://github.com/PyCQA/pylint/issues/7655>`_)


When copy pasting the release in github I currently have to remove the link manually (it's rst and github want markdown).

cdce8p · 2022-10-21T21:34:34Z

Just FYI Daniel suggested to create a backporting merge request and then a subsequent release branch to be able to review the release easily, let's do it next time :)

Not exactly sure what you mean. E.g. I needed to redo #7662 to include the merge commit.
Or just open it for comparison, do everything else, rebase / redo the backporting merge request?

Pierre-Sassoulas · 2022-10-22T07:54:15Z

Not exactly sure what you mean.

I meant opening a MR for the cherry-picking (backporting) in maintenance/2.15.x and another one for the release (tbump command) in maintenance/2.15.x before the release of 2.15.5. Like for #7591 / #7590.

That way it's easier to see what the tbump command did. It's the only thing that really need review at release time (if there wasn't any conflict during cherry-picking).

But, this is just a remark for next release: let's not redo everything for the sake of it, I do not mind reviewing everything in batch personally.

cdce8p · 2022-10-22T10:06:56Z

Not exactly sure what you mean.

I meant opening a MR for the cherry-picking (backporting) in maintenance/2.15.x and another one for the release (tbump command) in maintenance/2.15.x before the release of 2.15.5. Like for #7591 / #7590.

Think I got it now. So separating the backporting PR form the actual release. My impression was that it's easy enough to view just the last commit (the one from tbump) so it wouldn't be necessary. Additionally, IMO it's quite nice to have all commits regarding a patch release in one PR.

Pierre-Sassoulas · 2022-10-22T10:31:08Z

Think I got it now. So separating the backporting PR form the actual release. My impression was that it's easy enough to view just the last commit (the one from tbump) so it wouldn't be necessary. Additionally, IMO it's quite nice to have all commits regarding a patch release in one PR.

What do you think @DanielNoord ?

DanielNoord · 2022-10-22T10:32:57Z

For pylint the PRs can get very large. Since cherry picked commits can still be completely different than the actual commit we preferably also check those to make sure nothing bad slipped in.
Together with the many changes in contributors and new changelog generation those PRs got a little too big to review easily.

cdce8p · 2022-10-22T10:44:10Z

For pylint the PRs can get very large. Since cherry picked commits can still be completely different than the actual commit we preferably also check those to make sure nothing bad slipped in.
Together with the many changes in contributors and new changelog generation those PRs got a little too big to review easily.

They are large either way. Splitting it into two doesn't reduce the line count. IMO it's fairly easy to separate the changelog and contributor changes during the review with commit ranges. E.g. https://github.com/PyCQA/pylint/pull/7660/files/9c239c2eecb5925a4aabc73423c65eb67fdf151d

Creating a second PR is just more work and will make it more difficult later to understand what the actual release was.

Since cherry picked commits can still be completely different than the actual commit we preferably also check those to make sure nothing bad slipped in.

That's always an issue with cherry-picking for patch releases since theoretically you could hide something just in the maintenance branch. In the end, I think the best solution here would be to release more often so the diffs are smaller. Besides that only a select few (at the moment maybe we three) should do them at all.

Just for reference, this is a PR for a Home Assistant patch release. Note that the last commit / the version bump is included. home-assistant/core#80691

DanielNoord · 2022-10-22T10:47:04Z

Yeah, agreed but this was mainly due to the issues we had with the new changelog, contributor list and copyright notices. We had to rebase and force push many times. In those cases it was much easier to just merge the commits first.
A changelog change can easily be reviewed from mobile, that also helps.

I mean if you want to keep doing them like this that is also fine with me of course!

danmou and others added 11 commits October 20, 2022 11:28

Refactor check for ignored modules into reusable function (pylint-dev…

7c1d13f

…#7604)

Fix a false positive for simplify-boolean-expression when multiple …

aeec30a

…values inferred (pylint-dev#7627) Add a keyword-only `compare_constants` argument to `safe_infer`.

Upgrade astroid to 2.12.12 (pylint-dev#7649)

8cbc5a3

Add regression test for no-member with empty AnnAssign (pylint-dev#7632)

b051fab

Remove __index__ from unnecessary-dunder-call check (pylint-dev#7650)

c2d42ba

Use relative paths in create_contributor_list.py (pylint-dev#7656)

1579c43

Sort --generate-rcfile output

97ebe0b

Sort examples/pylintrc for 2.15.5

9c239c2

[doc] Upgrade the contributors list and CONTRIBUTORS.txt

8def9a0

Bump pylint to 2.15.5, update changelog

fc7dc5e

cdce8p added Maintenance Discussion or action around maintaining pylint or the dev workflow Skip news 🔇 This change does not require a changelog entry labels Oct 21, 2022

cdce8p added this to the 2.15.5 milestone Oct 21, 2022

cdce8p requested a review from Pierre-Sassoulas October 21, 2022 16:00

Pierre-Sassoulas approved these changes Oct 21, 2022

View reviewed changes

cdce8p mentioned this pull request Oct 21, 2022

Merge maintenance 2.15.x following the 2.15.5 release #7662

Merged

cdce8p merged commit bb17694 into pylint-dev:maintenance/2.15.x Oct 21, 2022

cdce8p deleted the release-2.15.5 branch October 21, 2022 21:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release 2.15.5 #7660

Release 2.15.5 #7660

cdce8p commented Oct 21, 2022 •

edited

Pierre-Sassoulas commented Oct 21, 2022 •

edited

Pierre-Sassoulas commented Oct 21, 2022

cdce8p commented Oct 21, 2022

Pierre-Sassoulas left a comment

Pierre-Sassoulas Oct 21, 2022

cdce8p commented Oct 21, 2022

Pierre-Sassoulas commented Oct 22, 2022

cdce8p commented Oct 22, 2022

Pierre-Sassoulas commented Oct 22, 2022

DanielNoord commented Oct 22, 2022

cdce8p commented Oct 22, 2022

DanielNoord commented Oct 22, 2022


		- Sort ``--generated-rcfile`` output.

		Refs #7655 (`#7655 <https://github.com/PyCQA/pylint/issues/7655>`_)

Release 2.15.5 #7660

Release 2.15.5 #7660

Conversation

cdce8p commented Oct 21, 2022 • edited

Description

Pierre-Sassoulas commented Oct 21, 2022 • edited

Pierre-Sassoulas commented Oct 21, 2022

cdce8p commented Oct 21, 2022

Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

Pierre-Sassoulas Oct 21, 2022

Choose a reason for hiding this comment

cdce8p commented Oct 21, 2022

Pierre-Sassoulas commented Oct 22, 2022

cdce8p commented Oct 22, 2022

Pierre-Sassoulas commented Oct 22, 2022

DanielNoord commented Oct 22, 2022

cdce8p commented Oct 22, 2022

DanielNoord commented Oct 22, 2022

cdce8p commented Oct 21, 2022 •

edited

Pierre-Sassoulas commented Oct 21, 2022 •

edited