[policy] Decide how long major Drupal versions should be supported

Problem/Motivation

Drupal 9.5 is only going to be supported for one year following 10.0.0 due to Symfony 4 and ckeditor4 EOL dates, a one year window for all contrib modules and all Drupal 9 sites to upgrade to a new major is too short but is also the current de-facto state for 9.5, and 8.9 was only slightly longer at 18 months.

#3238372: [policy] Decide on a 2 or 3 year major release cycle means that we will be in a better position to support Drupal 10 longer and a predictable schedule for the following major releases. The goal of this issue is to determine how long each major release can/should be supported, trying to balance the needs of site owners, contributed module maintainers, core committers, and the security team.

Symfony is not our only core dependency. PHP releases a new minor every year with a three year support cycle. Other PHP and JavaScript dependencies often have no formal support cycles at all.

@catch and I discussed this at length today and here is what we came up with. Given:

• We want to support Drupal 10 as long as possible.
• We need to at least provide minor dependency updates so D10 continues to have dependency security coverage throughout that time.
• Contrib not having API compatibility for supported branches creates upgrade barriers, so we want to provide key APIs simultaneously across major versions.
• But (per research by @lauriii) many site owners and even agencies consider site updates more risky than security vulnerabilities, so we want to have branches available that are more stable with fewer updates.
• And release managers know from D8 and on that internal API breaks are disruptive for contrib.

Proposed resolution

Using Drupal 10 and 11 as examples, but this would then apply to future releases unless we explicitly changed it. Also assuming that we release 10.3 and 11.0 at the same time, but this could start with 10.4 and 11.0 if that's when 11.0 gets released.

We will try to support Drupal 10 until 12.0 is released, with a definite maximum EOL of Symfony 6's EOL. The final EOL date is TBD and to be reviewed closer to the time based on how things are going.

10.3 and 11.0 follow the pattern we've done previously where we make the 'last minor' and 'first major' as close to each other as possible.

However, we will continue to release Drupal 10.4 and 10.5 minor versions, with

1. PHP version compatibility
2. Dependency updates
3. Backports of new API features, which we think will enable contributed modules to continue to support both versions easier. We would not backport everything, only issues which we think will make things genuinely easier for contrib modules without introducing instability to Drupal 10, and issues will be marked 'to be ported' after an 11.x commit - i.e. we won't require a backport MR up front.

10.5 would be released 18 months before Drupal 12.0, and after that point, we would only release patch releases of Drupal 10, to balance the workload of backporting with preparing to release Drupal 12. i.e. similar to what we are doing now for 9.5, just reaching that point much later in the cycle. We could still decide to do an 'extra' minor release if we get caught out by a dependency change but this would generally be for security support only and not change the EOL.

Detailed explanation

This introduces the concept of a maintenance minor, which is something between regular minor support and security support. It includes:

1. Minor-version dependency updates (plus CKEditor breaking versions).
2. PHP compatibility fixes for the latest PHP version.
3. API additions that were committed to D11, where these API additions are important API parity for contrib. These are backported as new APIs only, without any usage conversions. Release manager discretion.
4. No internal BC breaks insofar as it is possible.
5. Backports of safe major and critical bugfixes (those that do not require deprecations, internal BC breaks, or serious behavior changes).
6. Bugfix releases issued at release manager discretion rather than monthly.
7. Six months of additional security-only support after the six months of limited support, same as any other minor.

The release schedule plays out thus:

1. Drupal 11.0 is released alongside a minor version of Drupal 10, as per current practices. This is 10.3 assuming we release in June or August 2024, or 10.4 if 11.0 comes out in December.
2. When 11.1 is released, we issue a maintenance minor of Drupal 10. (Most likely 10.4, or possibly 10.5 in the December D11 scenario.)
3. 12.0 comes out in June 2026 along with 11.4 (or 11.3 in the December scenario).
4. In the December release scenario for 12.0, 10.5 receives at least 12 months of extra security coverage (rather than six) until December 2026, meaning it extends to the start of Drupal 12 support.
5. We may extend 10.5 further (to December 2026 even with a June 12.0, or into 2027 if that seems feasible and necessary), but we make that determination during Drupal 12 preparation and/or after its release.
6. When 12.1 is released, Drupal 11 then begins receiving the maintenance minors.

Additional notes and graphs

Documentation

This is documented at
Release process overview
Drupal core release schedule

Remaining tasks

• #3400644: [no patch] Update the release cycle process overview handbook page for the new major version schedule
• Allowed changes needs a maintenance minor section
• Other handbook pages?
• Announcement