What's left for 3.0?

[DanielNoord]

Just because I want to gather some thoughts before we can decide when to release 3.0.

For me the main blocker was always turning on --strict in mypy as that would lead to many deprecations. If we (ever) fix the typing in astroid we will likely see many more things we need to fix in pylint as well but at least it somewhat works now. That means I personally have only four main "stretch goals" for 3.0 that I can think of:

G1) Take one last look at multiprocessing and see if it can be fixed
G2) Create a new JSON reporter
G3) Overhaul the enable/disable vs. extend configuration
G4) Make a start with offering pylint configuration templates

I'm not sure if they should all be part of 3.0 but I think we should at least start a discussion about what our expectations are and align some of our goals. For me personally only G2 is a real blocker.
It might even make more sense to postpone G3 and G4 to 4.0 but start working on it immediately. We probably have some fallout from the 3.0 release as we deprecate a lot and can then make 4.0 the pylint-config and "Update-your-configuration-Update".
G1 I think is also very important as it refers to our current users. Although configuration is a pain for a new user, I think a much larger "threat" is people turning off pylint because it is too slow. It's just that we clearly lack the expertise/time to fix this right now.

So, what do others think? Are there any other features that should definitely go in 3.0? And what do you think is the right timeframe to think about?

[Pierre-Sassoulas]

In the same vein there's:

• Should pylint be equivalent to pylint . ? #5701 This one is a blocker but also trivial to implements.
• Search for pyproject.toml config file in parent dirs #7163 It needs to be discussed / reviewed merged asap, because the only reason blocking it is that we do not have a 3.0 branch yet.
• Disable certain messages by default #3512 it make more sense to apply it in 3.0 even if we do change this kind of thing in minors and it can be done when we decide to.
• Allow five digit message id's (and possibly disallow four digit id's) #5275 is related but I think it should be postponed indefinitely.
• We need to apply all the deprecation and breaking changes that are already planned and advertised. There's a lot, (a search for warning.warn with DeprecationWarning would already show a lot of thing.) It's going to be some work and as soon as we start this we're going to have to maintain the 2.x maintenance branch at the same time as we try to do the 3.0 release which could prove difficult.

G1 I think is also very important

Performance is important but it can be done in any releases imo.

For me personally only G2 is a real blocker.

Agree ! Everything else c/should be in 4.0 or later. But as @cdce8p said somewhere we should create the new JsonReporter in 2.x we only need to make it the default in 3.x.

Regarding the timeframe we could create the 3.0 branch right after releasing 2.16, merge #7163 in it and see where we goes from here. It's better if we don't have to maintain 2.X long enough to have a lot of conflict when cherry-picking but there's going to be some overlap. Once IDE integration (vs-code / pycharm) and major plugin (prospector / pylint-django) use 3.0 we don't have a lot of reasons to keep maintaining 2.X imo.

[DanielNoord]

We probably need to maintain 2.x for some time as I don't think many companies like bumping to majors. Especially around the end of year holidays. Ideally we would get main relatively stable with 2.16 or one more (2.17) release without any major new features.
I don't think we should rush this and also think we shouldn't underestimate how long people will ask for 2.x support. By releasing 2.17 without any major new features we further increase the chance of main actually being stable.

[Pierre-Sassoulas]

I don't think we should rush this and also think we shouldn't underestimate how long people will ask for 2.x support

I think that when we release 3.1.0 we should have no backport (my prefered solution 😄) or at least only limited backport in 2.X. This is the moment we would have 2 maintenance branches. I don't see myself backporting every false positives and bug fixes twice.

Users know that each pylint release means new messages so I don't think 3.0 will be that different. I think apart from the json reporter we don't have a lot of user breaking changes.

Breaking change in 3.0 are aimed more toward lib depending on us. If we get maintenance request from that, imo it's going to be unexpected and hard to solve (i.e. should we revert in 3.0 or is there a solution to make 'external lib' compatible with pylint 3). I don't think we should maintain 2.x for a really long time and not solve the problem in 3.0 but let me know what you think. Also we had a long deprecation period at this point so maybe it will not be that painful.

Also, I know a company that still use pylint 2.6.2 because it's the one downloaded by pypi when you're under python 3.5. We also had maintenance request for pylint 1.9 well into 2020 because some company did not switch to python 3. It doesn't mean we have to humor them on our free time and maintain python 3.5 / python 2.7 :)

[DanielNoord]

I think that when we release 3.1.0 we should have no backport (my prefered solution smile) or at least only limited backport in 2.X. This is the moment we would have 2 maintenance branches. I don't see myself backporting every false positives and bug fixes twice.

Ideally we would create some workflow for this. But agreed. We should do limited support for the maintenance branch.

Users know that each pylint release means new messages so I don't think 3.0 will be that different. I think apart from the json reporter we don't have a lot of user breaking changes.

I know that some companies also use other package managers which might be more hesitant with suggesting a major version. In my current job I know we're still on 2.14.x because nixOS doesn't have the more recent version for example.

Breaking change in 3.0 are aimed more toward lib depending on us. If we get maintenance request from that, imo it's going to be unexpected and hard to solve (i.e. should we revert in 3.0 or is there a solution to make 'external lib' compatible with pylint 3). I don't think we should maintain 2.x for a really long time and not solve the problem in 3.0 but let me know what you think. Also we had a long deprecation period at this point so maybe it will not be that painful.

Agreed!

Also, I know a company that still use pylint 2.6.2 because it's the one downloaded by pypi when you're under python 3.5. We also had maintenance request for pylint 1.9 well into 2020 because some company did not switch to python 3. It doesn't mean we have to humor them on our free time and maintain python 3.5 / python 2.7 :)

😄

[tushar-deepsource]

Hey! Do we have an optimistic schedule for 3.0 yet? Something along the lines of "1 month from now" or "6 months from now"?

[Pierre-Sassoulas]

There's no planning, but I would say it's more likely 6 months from now or more, depending on the availability of maintainers and the intensity of merge request proposed by contributors that we'll also have to deal with in 2.x while preparing 3.0.

[jacobtylerwalls]

I'd like to see us finish up and merge pylint-dev/astroid#1189 in the near future, and then the first set of pylint PRs that do smarter control-flow can be batched for 3.0

G1) Take one last look at multiprocessing and see if it can be fixed

Tentatively raising a hand to look at this in 2023.

Performance is important but it can be done in any releases imo.

True, but if G1 requires a rewrite (as some abandoned attempts in the past remarked), then better to look into it before 3.0.

[DanielNoord]

True, but if G1 requires a rewrite (as some abandoned attempts in the past remarked), then better to look into it before 3.0.

This is also what I'm afraid of...

[Pierre-Sassoulas]

I think that working on multiprocessing is above what I / we can do while still dealing the constant flow of issues and merge requests. Also multiprocessing is pretty hard to test correctly so I'm very afraid of touching it. If we go this path we might need to feature freeze and false negatives freeze until 3.0 is released to make it manageable. Now that I say it, it would only be like a minor release but we start maintaining the 2.X branch at the same time than the 2.16.x branch, and before we release 3.0. (the 2.X branch would in fact be the 2.16.x branch)

[DanielNoord]

The issue with multiprocessing being hard is also that we don't know how hard the fix will be 😅

The biggest issue I had so far is that I couldn't figure out the issue and only had hunches but no actual data (other than the issue I already fixed). The only thing I know right now is that there is a significant memory leak in astroid and that it feels (emphasis on feels) like we are using many global states that break multiprocessing.
Thus, perhaps things should in fact be solved in astroid without any changes to the pylint code, making a feature freeze unnecessary. At the same time, it is likely that we might want to change some (breaking) stuff in pylint so I agree with Jacob that it makes sense to at least narrow down the issue before releasing 3.0. Hopefully by narrowing down the issue we also get a better sense of the scope/location of the fix.

[Pierre-Sassoulas]

@cdce8p @jacobtylerwalls @DanielNoord now that 2.16.0 is out, I was thinking of doing a very light/fast release for 2.17.0 then start a 3.0 branch and release more alphas then betas until we can actually release a proper 3.0. I feel like if we do an enormous 2.17 release (with as much features as 2.16) we're never going to actually start 3.0 😄

[DanielNoord]

I'm fine with releasing 3.0 although I think we might need to release 4.0 shortly after when astroid also has a 3.0 release.

Personally I'm more interested in cutting off the 3.0 astroid branch and start progressing towards py.typed and some of the needed breaking changes there but I think pylint 3.0 can be cut off as well.
The main reason why we use semver is for plugins, users should be able to update relatively easily. The plugin ecosystem for pylint is not necessarily thriving and the current planned breaking changes are easy to solve, so let's go ahead!