Policy: target Drupal 11 for August 2024 with a December 2024 fallback

We need to decide this before the end of this year at the very latest, bumping to critical.

Updating title, tags and version number based on recent announcement at https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →

What else needs to be done here to "decide this before the end of this year at the very latest" (as @catch wrote)?

We discussed this briefly recently, somewhere, I can't remember where now, and I think with the longer 10.x cycle + longer trail off for minor releases, we decided it would be simplest to keep the June, August, December release windows for Drupal 11, even if we think it's probably unlikely we'd hit the June one. This way we can standardise all major release documentation for the next x releases rather than having to special case yet again.

I've updated the issue summary to reflect that.

What/who else is needed for this to become a decision and documented among the release dates?

I've pinged the other RMs just in case, but I think at least one of them was in that discussion. Marking RTBC. The only change from the long-discussed plan is that we will document a June window that we think we might miss, rather than ruling it out entirely, so that we can have documentation and announcements that will apply for future major releases too.

I opened 🌱 [11.x] Communicate if/when we decide to skip the June 2024 release window for releasing 11.0.0 Active as a followup.

I remember discussing this briefly as well but also don't remember where. My concern was that if we drop the June window and initially aim for August then we risk missing December as well, given that the harder parts of the work are often left until the last minute. If we aim for June then we have more time to run into issues and discover unknowns.

The biggest concern with the June window was that it is only 18 months after 10.0 and we want to try and avoid upgrade fatigue given that many users are only just leaving Drupal 9; while we intend to support 10.0 for longer the messaging on all this still needs to be communicated correctly.

I agree with #22, FWIW. I think the proposed followup is wontfix, and instead we just follow the normal three-window major release policy.

Also, the 11.0.0 announcement could include something like:

Tired of upgrades? Don't worry -- you have two years to upgrade from Drupal 10 to 11.

I too recall a discussion and the 'update fatigue' that @longwave mentioned and that is a concern for me. However, to balance that we now have agreed to a 2 year cadence and a plan for providing Long Term Support. I think that providing that long term predictability improves the ability of sites to plan upgrades and offsets some of the possible fatigue. In the end I agree to our standard policy of the three windows and target for June.

That's confirmation from all of the release managers now, and we've also closed 🌱 [11.x] Communicate if/when we decide to skip the June 2024 release window for releasing 11.0.0 Active since it'll be 'when we know we're going to miss the beta deadline for a June release'. So I am going to go ahead and mark this issue fixed.

Since this is already the status quo and documented on https://www.drupal.org/about/core/policies/core-release-cycles/release-p... → , and 🌱 [policy] Decide how long major Drupal versions should be supported Needs review is still open for co-ordinating the 10/11 release cycle announcement, going to go ahead and mark this one closed.

Automatically closed - issue fixed for 2 weeks with no activity.

@Gábor Hojtsy noticed a mistake in the issue summary with the August release window - I've retrospectively edited it to match the 10.x windows and the documentation on https://www.drupal.org/about/core/policies/core-release-cycles/schedule →

Also writing up how it works in case we refer back to this for Drupal 12.

To release 11.0.0 in June, it needs to have a beta release before the usual beta window for a June minor release.

The August window gets used if 11.x is beta-ready by the time 10.3.0 reaches its usual beta deadline. In this case they both get beta releases in the same week, but since 11.x's pre-release phase is longer, the 11.0.0 release comes out in August.

This way, 10.3.0 comes out when it normally would regardless of what happens with 11.x, but if we narrowly miss getting 11.x ready for June, we can release it two months later instead of waiting the full six months until December and 10.4.0.

Update version to the branch this applies to.