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.

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.

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 :)

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 :)

😄

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"?

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.

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.

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...

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)

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.

@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 😄

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!

I don't see any issues with releasing 4.0 soon after, 3.0 was delayed a lot because planning and promises were made by contributors that are not very active anymore and we had to do a lot of things to discover and keep or break those promises. The deprecation cycle could become shorter (months instead of years) imo.

There's only one PR left on the 3.0.0a7 milestone, which is almost ready to merge. But we've already bumped pylint to 3.0.0b1. It would be sort of nice to keep pylint and astroid in a similar release cadence. (Don't think it's a good idea to publish a stable pylint that depends on unstable astroid.) Would also be good to support python 3.12 in an astroid beta, if not the first one. Reason: I don't want to encourage a lot of testing until we're ready for 3.12.

@Pierre-Sassoulas how do you think we should proceed? I may not have time to contribute anything else for 3.0 except reviews and supporting python 3.12.

I bumped to beta in pylint prematurely I don't mind downgrading to be able to release before doing #3512. But since I made some changes that will requires annoying manual modifications in user conf I would like to do the automatic upgrade of conf before releasing a new pylint alpha. (Finding the time to implement it proved challenging though)

@DanielNoord I started a discussion on Discord about releasing betas of pylint/astroid as soon as we can. Python 3.12 is almost out, and I'd like to see pylint accrue the "reputation points" from supporting it on time this year. If we're going to leave time for actually responding to beta issues, we need to start encouraging testing.

3.0 doesn't need to be huge, it has plenty of performance and usability enhancements to justify the breaking changes involved already.

I think @Pierre-Sassoulas wants to wait a bit until we have the auto-config-upgrade feature, but I'm not sure we need to wait, since we can also use the beta period to revert any changes that users find too difficult/tedious to upgrade. I'm also not sure which PRs are the ones that we're considering blocking the beta over this. I read the 3.0 changelog in progress and only spotted the overgeneral-exceptions change; we could consider just reverting that instead.

The new JSON reporter can be added in a 3.x and not removed until 4.x, so that's fine, also.

WDYT?

Completely agree! All meaningful API changes have been deprecated long enough and are available as alpha's as well.

I'd really like to work on the auto-upgrade feature but it is just too much work for the little time I have left to work on OS at the moment.

I think it is indeed also fine to release major versions more often. For 3.x I think there were just so many outstanding issues that we didn't know when to cutoff in a smart way, I agree with your assessment that it is seems like we're there now!

Like I said elsewhere I'm on limited internet for a couple of more days so I won't be of much help but feel free to do the release. If necessary I should be able to respond to issues I'm tagged in within 48 hours.

Happy autumnal equinox! ☀️ = 🌑

Like I said elsewhere I'm on limited internet for a couple of more days so I won't be of much help but feel free to do the release.

It seems @DanielNoord and I agree that we've been ready to release 3.0 for about two months now. I wanted to bump this thread to see if we can drive at some sort of compromise/plan.

Python 3.12 is almost out, and I'd like to see pylint accrue the "reputation points" from supporting it on time this year.

(I find it a little unfortunate that we're going to miss this target.)

@Pierre-Sassoulas, am I correct that you feel some degree of conviction about waiting for certain features you regard as blockers? I don't know that we ever had a full discussion about marking them as blockers, and even if Daniël was a part of such discussions, he sounds willing to revisit them now.

I just don't think any of the issues labeled with "blocker" are important enough to block a release. In 3.0 as things currently stand, people might need to replace some calls to deleted extensions or update their overgeneral-exceptions setting, which we've already been bothering people about with warnings. Doesn't seem significant to me. A helpful tool is not a breaking change; we can ship it as fast as we feel it's ready.

If we polled users (and I guess we might need to if we can't get to an agreement), we could ask whether they'd rather have faster pylint and 3.12 compatibility now, or wait six months in case we can dev/test an auto-updater to (potentially) make two changes to their config file, my guess is that the first would be more popular, but I'll happily support whatever the community decides.

we can also use the beta period to revert any changes that users find too difficult/tedious to upgrade. I'm also not sure which PRs are the ones that we're considering blocking the beta over this.

This is still an option. (And a good lesson for us, to do our best to avoid merging things we're not fully sure we can release or make promises about timelines.)

Many thanks as always for the love you all show this project on a continual basis! ❤️

I also want to release at the start of October (for python 3.12 release).

I don't like releasing something with known crashes. But those seems to happens in exceedingly rare occurrence and are already happening in 2.17.X and I don't see a flood of reactions or contribution on those issues, so I removed the blocker label on them.

I think #3512 will need to go in 4.0 even if it pains me a little (there's much anticipation on this one). There's no way to reasonably / correctly do it in a week and it would really benefit from #5462. And once we're finally free from past promises or dare break them, we can release major as often as we want...

#5462 is a "should have" and #5701 a "must have" imo. I'm working on #5701 that is surprisingly hard to implement atm, but I think it's reasonable to do it. I aimed to do #5462 in 6 days rather than in 6 months, but I might be surprised by the difficulty (especially if we must deal with pylint configuration / option parsing to do it), How about we reassess #5462 in 6 days ?

Everything else can just be moved or the milestone removed. But I don't think we should block MRs from being merged if they are ready either.

🙏 sounds like a plan. Thank you for volunteering, and I'll keep near to GitHub for reviewing and any other maintenance chores.

I don't have much time for writing code, but I'm keeping any on notifications and available for reviews if required!

I moved all the issue that were labelled "needs decisions" or "breaking changes" from the 3.0.0 milestone to the 4.0.0 milestone. I removed the milestone of everything that was not labelled "needs decisions" or "breaking changes" or something that need to be in 3.0.0 from the 3.0.0 milestone. I updated the descriptions of the milestones so that #3512 is now planned for 4.0.0b0,

What I think must/should/could be done for the 3.0.0 release now:

• Release last 2.17.x version Bump pylint to 2.17.6, update changelog #9064
• Release astroid 3.0.0 Bump astroid to 3.0.0, update changelog astroid#2303
• Release pylint 3.0.0b0 Bump pylint to 3.0.0b0, update changelog #9065
• Should pylint be equivalent to pylint . ? #5701 / pylint equivalent to pylint . #9072
• Provide an auto-upgrade option / migration tool for pylint configurations #5462
• HELP WANTED: Help copy content from pylint-errors over to our own documentation #5953 ? (2 messages left, typevar-name-incorrect-variance and c-extension-no-member, announcing that the doc is complete for 3.0 would be nice)
• Release pylint 3.0.0

rename to 3.0.0b0

Perfect!

Python 3.12 is out and we're receiving issues like #9091 because 2.17.7 is used unless you use --pre in pip. Probably more reasonable to release 3.0.0 without the last items and do them in 3.0.1 or 3.1.0 asap ? I don't think compare-to-zero and compare-to-empty-string are as widely used as an ex-default check like no-self-use. Also I'm traveling for work this week and it does not look like I can close a basic version of the auto-upgrade tool before thursday. What do you think ?

🚀 : release 3.0.0 now
👀 : wait for #5462

Yeah, the config tool can ship anytime, it's a nice to have, not a breaking change.

It's done: https://pypi.org/project/pylint/3.0.0/ ! On the same day than python 3.12. I remember the day where we were lagging behind 3.9 and it annoyed Marc to the point of deciding to fix it and join the contributor team 😄. It's also a major version, there's a huge work involved to get to this point, and it's been planned for almost 10 years. A big thank you to everyone who made that possible.

Yes, many thanks for everyone's hard work!

Nice work team!