(❓) 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.