(❓) Should minor versions have pre-releases

[KotlinIsland]

Question

2.13 came with a fair few issues and required three patch releases within 4 days. If there were publicized pre-releases the community would have had a chance to report these issues before a general release.

Documentation for future user

I'm always willing to test pre-releases and raise issues

Additional context

No response

[Pierre-Sassoulas]

The number of patch releases is greater since #5858 because we're backporting all false positives fixes all the time. Before that we were only fixing crashes for a short period of time. So more and faster patch releases was expected for 2.13 and is not necessarily a bad thing. Before that we were just waiting longer to release and not releasing fixes until the next minor. (See for example 2.13.2)

It's possible to test the latest pylint without pre-release from us by using pip install -U git+https://github.com/PyCQA/pylint.git@main. We appreciate if you're including bleeding edge pylint in your project CI and tell us if we break something (we have a limited number of runner for our primer we can't just tests every repositories).

That being said we can pre-release minors if it's useful. We could even release 2.14.0a0 right now. I think a little more automation would be required if we release weekly or more, but nothing is impossible.

[DanielNoord]

To add to what @Pierre-Sassoulas said:

1. I think releasing minor version a little sooner than we did with 2.13 should help. We had a lot of issues getting that version out which then increased the size of the release and thus the potential for new bugs.
2. I think pre-releasing/nightly builds could certainly be interesting but only if we find a way to do this automatically with a Github Action. Maintenance-bandwith is limited as for every project and I think I'd rather invest time in a better primer and other mitigation strategies for future bugs.

[DanielNoord]

@Pierre-Sassoulas Would you be able to release a pre-release for 2.14. I'd really like some additional tests for the configuration changes.

I don't think there is much left that should go in a pre-release, most of what's left of argparse is just nice to have. We also deprecated everything we wanted to so we can also get feedback on those decisions early.

[jacobtylerwalls]

I think it would be 🥇 to also get in these into the pre-release:

• Rename cache-max-size-none and check functools.cache #6182 (for feedback)
• 'str' object has no attribute 'parent' #6221 (get an astroid patch out so users don't report this again)

[Pierre-Sassoulas]

All right let's do this at the same time than we release 2.13.6.

[DanielNoord]

@Pierre-Sassoulas astroid is ready for a patch release as the milestone is now completed.

After that we can do a patch release on pylint and do a pre-release as well.

[Pierre-Sassoulas]

Releasing astroid 2.11.3 is harder than anticipated, I had to cherry-pick a lot of dependencies changes without which pre-commit and tbump fails.

[Pierre-Sassoulas]

pylint now has an upgraded astroid version following the release of astroid 2.11.3 and #6398, I'm going to:

• Merge Add an option to disable sys.path patching. #5235
• Release pylint 2.13.6
• Merge Do not append namespace packages to sys.path #6405
• Merge Deprecate interfaces.implements #6403
• Cleanup the changelog and create a deprecation section Release branch 2.14 beta #6527
• release pylint 2.14.0b0 Release branch 2.14 beta #6527
• close this issue

[Pierre-Sassoulas]

As #6221 was merged I think we can release 2.14.0b0, what do you think @jacobtylerwalls @DanielNoord ?

[DanielNoord]

Well if we're doing a beta release we might as well consider #6405? That seems like it could break many things 😅

I'm less worried about the __implements__ stuff as that won't break much, we just need to find the right way to communicate its deprecation.

[DanielNoord]

@Pierre-Sassoulas One thing to add to the TODO:
Clean the changelog. Because of the amount of deprecations we might want a dedicated deprecated section in the notes. Especially for the beta as we want people to see if the removal and deprecation of stuff breaks anything.

[DanielNoord]

@Pierre-Sassoulas I think we can release the beta now right? I have also cleared up the 2.14 milestone a little so that we can actually release it at some point!

[Pierre-Sassoulas]

Yes, let's clean up the deprecation in the changelog in the 2.14 release branch and release the beta.