Todo/to-do list for 2.15.0

[DanielNoord]

TODO:

• Fix any outstanding TODO: 2.15: comments
• Integrate latest astroid patch
• Revert [test] Temporary xfail deprecated methods py36 on pypy #7244
  Opening this now to track discussion on our next major release.

[DanielNoord]

One of the things I would like to discuss is to reserve the milestone for actual user-facing changes. I just had a look at the 2.14 milestone and its closed tab is pretty unusable. I have done this myself as well, but by adding all changes to documentation and our CI runs it's not actually clear what real changes were made to the code/functionality. A related issue is that the number of closed issues/PRs no longer is a good indication of how "impactful" a release might be. Normally the number of closed items is a good indication of the number of changes, but will all the documentation PRs this is no longer the case.

Obviously there will always be a balance somewhere, but I would like to propose to only add new functionality, bug fixes or refactors of actual code into the milestone. If people want to see all commits between 2.13.0 and 2.14.0 they can use git to tell then.

[Pierre-Sassoulas]

Regarding user-facing or not in #5728, I'd like to separate clearly what is user facing from what is useful only for pylint's devs. I'm going to enforce a regex, maybe the current (\*\s[\S[\n ]+?]*\n\n\s\s(Refs|Closes)) #\d{1,5} maybe something with only the PR in parenthesis like black * yadayada on a single line (#6632) (I think changing the style of the release notes makes sense as the PR will be linked to the issues anyway, and it's easier to check that the PR number is in the whats'new because we have access to it from the CI). It's still a work in progress but I can push the draft if you're interested.

Regarding the milestone, I'm using it as a big todo list to see what still need to be done. I think it's a good thing to have every issue/PR from a version to be in the milestone. It's possible to check what you want to check by excluding label or requiring labels for example this indicate that we have currently 136 meaningful issue in 2.14 : https://github.com/PyCQA/pylint/issues?q=is%3Aclosed+milestone%3A2.14.0+-label%3A%22Documentation+%F0%9F%93%96%22+-label%3Adependency+-label%3AMaintenance

The way to do that is at the bottom of the label list in the interface.

[DanielNoord]

I'd like to separate clearly what is user facing from what is useful only for pylint's devs.

👍

Regarding the milestone, I'm using it as a big todo list to see what still need to be done.

I like to do this as well for issues, but for some PRs it doesn't make a lot of sense.

I think it's a good thing to have every issue/PR from a version to be in the milestone.

Imo, changes to the documentation are not "from a version". We don't include the doc directory in our builds and I think they exist separately to the actual program. Same goes for dependency upgrades in our (pre-commit) toolchain.
I think the milestone can help outside users/developers get a quick overview of everything that went into a release without knowing all our labels and project management specifics. (I often look at project's milestone to see what was done in the latest release when browsing repo's) However, in our project that is no longer possible without knowing our labels.

Since the issue/PR interface doesn't show closed milestone this is also not really user-friendly.

But if you don't agree then let's keep putting everything in the milestone.

[Pierre-Sassoulas]

We don't include the doc directory in our builds and I think they exist separately to the actual program.

Right, let's remove maintenance/documentation/dependency from the milestones.

[Pierre-Sassoulas]

Maybe not maintenance as it's often refactor that touch the code ?

[DanielNoord]

Maybe not maintenance as it's often refactor that touch the code ?

Yeah like I said, I think those are often grey areas where we'll need to find a balance. For example: a PR that adds copyright notices to all files or that reshuffles test files is not really something that is part of a "version" I think. Refactoring to use argparse instead of optparse is though, even if all of these don't get a changelog entry.

[Pierre-Sassoulas]

Alright, I'm going to enforce the need to have a changelog entry according to the label on an issue.
So "documentation", "dependency" and "maintenance" should be exempted... except if they've been added to the current milestone. The decision of changelog or not will be taken by maintainers when assigning label / milestone to a pull request.

[jacobtylerwalls]

From discussion on a recent astroid PR:

There's two issues left in 2.12, including this one that is mergeable, should we even release 2.11.7 ?

@Pierre-Sassoulas fine with me to skip it! We could also probably skip pylint 2.14.5 then.

How's this sound?

• release astroid 2.12 with Support "is None" constraints from if statements during inference astroid#1189
• work on pylint compatibility with astroid 2.12
• work on pylint compatibility with python 3.11
• freeze pylint 2.15 (don't add more to the milestone)
• evaluate milestone, bumping harder things to 2.16 (will much easier with a bunch of astroid stuff cleared out)
• release 2.15

[Pierre-Sassoulas]

Sounds good !

work on pylint compatibility with astroid 2.12 and python 3.11

Not sure if possible yet as we rely on dill being compatible with 3.11 (I'm fine with pylint 2.15 not being compatible with python 3.11)

[jacobtylerwalls]

Regarding pylint-dev/astroid#1189 I reread Marc's review comment,and he refers to intending to do a "subsequent" review, so I'm wondering if we're better off releasing 2.12 right now and getting on with clearing the Pylint PRs. Tomorrow's another day.