Backport (#7987)

[clavedeluna]

Type of Changes

	Type
✓	🐛 Bug fix
✓	✨ New feature
✓	🔨 Refactoring
✓	📜 Docs

Description

Manual backport from this PR #7987

[coveralls]

Pull Request Test Coverage Report for Build 3822350789

• 15 of 25 (60.0%) changed or added relevant lines in 2 files are covered.
• 14 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.1%) to 95.178%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pylint/checkers/utils.py	10	20	50.0%

Files with Coverage Reduction	New Missed Lines	%
pylint/checkers/classes/class_checker.py	14	93.35%

Totals
Change from base Build 3789551874:	-0.1%
Covered Lines:	17114
Relevant Lines:	17981

---

💛 - Coveralls

[Pierre-Sassoulas]

The pre-commit error seems genuine but also it seems it might be pre-existing ?

[clavedeluna]

I believe I've cherry-picked the right commit to fix the issue.

[Pierre-Sassoulas]

The problem with pre-commit will be fixed with DanielNoord/pydocstringformatter#214

[DanielNoord]

I don't really understand. This issue should have been fixed in a release that was already released and is being used by pre-commit. I'm rerunning the CI.

[DanielNoord]

Ah, we need to cherry pick the pre-commit config as well. The maintenance branch is using 0.7.0 which is indeed broken.

[clavedeluna]

@DanielNoord ok since you know a bit more about what's going on, I'll let you handle any removal of commits here or anything like that.

[DanielNoord]

@clavedeluna You can just copy the .pre-commit-config.yaml from main to this PR. That should fix it 😄

[Pierre-Sassoulas]

I've done it (6acd437) but this is not that simple. I think we should release astroid 2.13.0 and pylint 2.16.0. Cherry-picking is not working automatically half the time right now, cherry-picking all the pre-commit upgrade is going to be a lot of work.

[clavedeluna]

Since this is causing so much trouble, I have to ask something that's been on my mind for a few weeks. Is the backporting procedure an absolute necessity for pylint? Could the repo not benefit from always forward-looking release of code? Or what is the great benefit of backporting certain PRs to an already-released minor version? I guess it's to avoid having to tell people to upgrade?

[Pierre-Sassoulas]

We were doing the "simple version" without cherry-picking at some point, but it means we can't release some time, or we can't merge enhancement some of the time, or we introduce new bugs with each version, or we do not follow semver... Right now the problem we have is that 1189 in astroid is stuck and we did not release for a long time with a lot of change on the main branch since. I'm very close to merging 1189 now and dealing with small comments later.