Considering how many accepted changes are still being worked on (PEPs 684, 687, 688, 695, 697 at least) and still being decided on by the SC (PEPs 649, 702 and 709), I’m planning to postpone feature freeze and beta 1 for 3.12 by two weeks, without changing the rest of the schedule.
(Alternatively, if upstream distributors have a pressing need for a release named ‘beta 1’, I can postpone just feature freeze and release a feature-incomplete beta 1, but I would rather not.)
If you’re still working on changes you want to get into beta 1, please don’t wait until the last minute to check them in – preferably get them in two weeks from now at the latest.
For the record: the postponement is just for the changes already in flight. Please don’t try to squeeze in more features because we have two more weeks. (Bugfixes are fine, of course.)
Please don’t do this. I would just recommend postponing beta 1 and keeping it aligned with feature freeze.
I still want to get in my branch for import system API deprecation removals. It’s complete (modulo some doc updates) and awaiting review. I don’t think it would be too affected by postponement or not.
Well, these APIs have been deprecated since 3.4, so Is there really any value for waiting another year? I dread trying to keep the branch up-to-date until 3.14.
The branch has been ready for months. The blockage for earlier merging was in getting pip settled. Now that’s resolved, it unblocks this work. I guess ultimately, it’s the RM’s call but I see no reason not to move forward.
We could discuss this separately, but let me ask, what’s the rationale to move planned removals earlier? We know downstreams don’t test with alphas, so I’m not sure what it would buy us.
That makes it better I suppose. AFAIK we don’t have an official policy about when deprecated-slated-for-removal APIs should actually get removed within the dev cycle. OTOH, it’s not like postponing these removals really helps downstreams. They are going to have to adapt sooner or later and they’ve had years of heads-up. Plus, we have a 5 month or so beta cycle, so that should be time for downstreams to prepare for 3.12.
Not necessarily. Thomas already said that the delay would just be for the in-flight PEPs, so one implementation could be to branch off 3.12 as scheduled on May 8, and then for the pending PEPs only, do a backport to the 3.12 branch after merging into main, then release 3.12 beta 1 off the 3.12 branch in two weeks. That way you can already start working on new improvements on main. If that results in any merge conflicts for the PEPs I’m working on, I’ll happily take care of them.
Jelle, I feel like this is more trouble than it’s worth with an unprecedented setup. Mark is right that it’s worth keeping 3.13 development time in mind but I don’t think two weeks will make or break any feature work.
I suggest we just move one thing: the beta 1 date. Everything else stays as usual in the process.
Since there isn’t a lot of objection, I’m postponing the release until May 22, but please use this only for features that are already scheduled for 3.12 (and bugfixes).
– preferably get them in two weeks from now at the latest.
Is there really any value for waiting another year? I dread trying to keep the branch up-to-date until 3.14.