Repository navigation
When should we start accepting PRs for future Python versions #12569
Description
Since this has come up a few times recently: When should we start to accept PRs for the next Python version? I think it's fairly uncontroversial that at most we accept PRs for the current in-development version (currently 3.14). But I remember that previously we said, we shouldn't accept PRs before the first beta, since there's too much churn before that with removed and changed features etc. It also makes it easier to just diff the changes to the last Python release to see what needs to be changed. On the other hand, the earlier we accept PRs, the less work it will be when the first beta releases? I see a few options:
- Immediately when the previous release (3.13 currently) is branched from main.
- When the first alpha is released.
- When the first beta is released.
- When the first rc is released.
Personally, I think we should only start to accept PRs when the first beta releases for the arguments mentioned above. This gives us five months to the release. But I'd be fine with the first alpha as well to have a clear cut-off point, but not earlier than that. This would give us a full year.
For reference, we currently have 29 instances of (3, 14) in the stdlib. (Which we should keep regardless of the policy we're going to adapt.)
Activity
AlexWaygood commentedon Aug 21, 2024
Yeah, I agree. One recent example of a 3.14 addition that has already changed since it was added to typeshed is #12474. The method has already been renamed from
rmtreetodelete: python/cpython#122368; this kind of churn is really common during the alpha period.typing.ByteStringhas also been removed in 3.14, and that's already been reflected in typeshed, but I'm not sure if it should have been removed so quickly from the stdlib. The deprecation schedule was quite aggressive and the deprecation warnings were quite hidden, soaiohttphad no warning ofByteString's removal before I filed aio-libs/aiohttp#8408. I was considering proposing to revert the removal for now (and adding some more prominent deprecation warnings instead) during the Core Dev Sprint next month. If so, we'd have to revert #12490.Overall, in my opinion it feels like the maintenance burden and churn of PRs prior to the beta period isn't worth it.
Document policy for future Python versions
Document policy for future Python versions (python#12592)
Document policy for future Python versions (python#12592)