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.

[DanielNoord]

Yeah, although I would have liked to put it in. Let's not block this, we need 2.12 for Python 3.11 support as well.

Perhaps we can release a 2.13-alpha after that PR lands? I'd like to see the impact of the PR on the control flow issues in pylint and whether this is the best approach for them before we start building upon the new constraints system.

A quick scan of astroid shows that there is only one other "finished" PR that could potentially go in 2.12 which I'll shamelessly plug here: pylint-dev/astroid#1598.
Fine with me if we don't find the time to review it. It introduces the concept of _explicit_instance_attrs which is something we should probably think carefully about.

[jacobtylerwalls]

Fine with me if we don't find the time to review it. It introduces the concept of _explicit_instance_attrs which is something we should probably think carefully about.

Yeah, let's not rush it. I think 2.12 could go out now, and I'd be eager to start focusing on making pylint compatible with it.

[Pierre-Sassoulas]

I'm on mobile at the moment because my pylint/astroid setup died yesterday, if someone want to release astroid 2.11.7 / 2.12.0 using doc/release.md, I would be glad. I don't know how long it will take to get back to normal right now.

[DanielNoord]

2.12 was just released.

@jacobtylerwalls Do you want to see what problems arise when we use it in pylint 2.15? 😄

[jacobtylerwalls]

@DanielNoord Up for a 2.12.1?

[Pierre-Sassoulas]

I have a new setup, I'll do it. See pylint-dev/astroid#1698

Edit: Just released. I'm going to fix contributors-txt now.

[jacobtylerwalls]

Ring ring! What do you say, is it release time? 🔔

I think we should bump everything (and I mean everything) that's not already got an approving review to the next minor version, and then release this week.

• astroid 2.12.3 with Fix false positive with inference of http module astroid#1742
• bump astroid to 2.12.3 in pylint
• deal with reverting [test] Temporary xfail deprecated methods py36 on pypy #7244
• merge any test PRs depending on 2.12.3
• Bump TODOs to the next minor version in preparation of release #7349
• that's it, release 2.15 (optionally with a pre-release, but no one tested it last time that I recall?)
• start backporting false positive fixes to 2.15.x

We can support Python 3.11 in a patch update anyway. Or in 2.16 if we target midfall (makes sense also if 2.15 is going out end of August.) dill can keep taking their time.

[DanielNoord]

I have done some project maintenance on the milestone.
@Pierre-Sassoulas There are a number of issues where you added the 2.15 milestone. For some I could determine why but there are still some where I don't understand why they are in the milestone. Could you have a look?

@jacobtylerwalls Would you mind putting pylint-dev/astroid#1749 in as well? The code was already approved by Pierre, it just needed a test which I just added. I cherry picked all other PRs already.

I have also added bump TODOs to your check list. There is one in the codebase which should be bumped to 3.x I think.

[Pierre-Sassoulas]

Sure, I'll have a look. Some issue I labelled 2.15 so we take a decision but it can be delayed to later (we just need to take a decision at some point and not let the issue rot).

[Pierre-Sassoulas]

I released and I'm trying to upgrade astroid in pylint in #7333

[Pierre-Sassoulas]

Opened #7345

[Pierre-Sassoulas]

Seems like the only MR that needed an astroid update in 2.15.0 is #7333

[jacobtylerwalls]

Seems like the only MR that needed an astroid update in 2.15.0 is #7333

That makes sense, since we're just going from patch to patch.

[Pierre-Sassoulas]

I've done some cleanup if the milestone there's 1 issue left now. Should we wait or investigate on #6986 or remove it from the milestone too ?

[DanielNoord]

@Pierre-Sassoulas I have some time right now. I'll do a quick investigation and come back in an hour if I can't fix it easily.

Edit: @Pierre-Sassoulas issue has been resolved 😄 I only want to point out my comment #7347 (comment). That's the last thing potentially blocking us from releasing I think.

[Pierre-Sassoulas]

Remaining to review/approve before release:

• [literal-comparison] Make the message more explicit with the solution #7354 for R0123 (literal-comparison) message is not explicit about the problem and the solution #5237
• Upgrade astroid version following 2.12.4 release #7356 (This one's primer can't work, we need to merge as is)
• Release branch 2.15.0 #7355