Problem/Motivation

If we use Drupal 9 as our status quo, then our status quo is:

  • For a new major Drupal version, set the minimum PHP version to the 2nd to latest PHP version available (e.g., Drupal 9.0 was released in June 2020, PHP 7.4 was already released 6 months earlier, but we set the minimum to PHP 7.3).
  • Release the next major version 2 years after the last one (e.g., release Drupal 10.0 2 years after 9.0 was released).
  • After releasing the next major version, provide security support for the previous one for an additional 17 months (e.g., after releasing Drupal 10.0 in June 2022, continue supporting Drupal 9 until November 2023).

The above was forced by the fact that we released Drupal 9 on Symfony 4 rather than Symfony 5. However, it's looking likely that we'll be able to release Drupal 10 on Symfony 6 rather than on Symfony 5, which gives us the ability to either choose to maintain the same cycle as above or to decide on a different one. It would be good to pick the cycle we want for Drupal 10 ahead of Drupal 10.0's release, since it could impact certain decisions such as the PHP minimum for Drupal 10.0.

Proposed resolution

Option 1

Keep the same 2 year cycle + 17 months of continued support for the prior version:

  • Release Drupal 10.0 in June 2022 on Symfony 5 with a PHP 8.0 minimum.
  • Release Drupal 11.0 in June 2024 on Symfony 6 with a PHP 8.2 minimum. Keep supporting Drupal 10 until Nov. 2025.
  • Release Drupal 12.0 in June 2026 on Symfony 7 with a PHP 8.4 minimum. Keep supporting Drupal 11 until Nov. 2027.

Option 2

Keep the same 2 year cycle, but switch to up to 29 months of continued support for the prior version, and set the PHP minimum for a new Drupal major version to the latest available:

  • Release Drupal 10.0 in June 2022 on Symfony 6 with a PHP 8.0 minimum (unchanged from option 1, because we're not extending Drupal 9's support period).
  • Release Drupal 11.0 in June 2024 on Symfony 7 with a PHP 8.3 minimum. Keep supporting Drupal 10 until ~Nov. 2026.
  • Release Drupal 12.0 in June 2026 on Symfony 8 with a PHP 8.5 minimum. Keep supporting Drupal 11 until ~Nov. 2028.

Note that the extended support for the prior major and the higher PHP minimum help enable each other, both because it allows people on the earlier PHP version to continue using the earlier Drupal version for a sufficient amount of time, and because the higher PHP minumum enables providing the longer support of the Drupal version.

Option 3

Switch to a 3 year cycle. This one is a bit more complicated because Symfony is on a 2 year cycle, but it's possible because of how long Symfony supports its old versions. Essentially it involves skipping a Symfony version every other Drupal version, as follows:

  • Drupal 10 on Symfony 6
  • Drupal 11 on Symfony 7
  • Drupal 12 on Symfony 9
  • Drupal 13 on Symfony 10
  • Drupal 14 on Symfony 12

However, that means that the odd Drupal versions can only be supported for a maximum of 17 months beyond the even Drupal version release, as is now the case for Drupal 9. While in this model we could potentially choose to support the even Drupal versions for longer, for simplicity, I'll present this option as having the same pattern for each version, which is 17 months of support for the prior Drupal major:

  • Release Drupal 10.0 in June 2022 with a PHP 8.0 minimum.
  • Release Drupal 11.0 in June 2025 with a PHP 8.3 minimum. Keep supporting Drupal 10 until Nov. 2026.
  • Release Drupal 12.0 in June 2028 with a PHP 8.6 minimum. Keep supporting Drupal 11 until Nov. 2029.

Note that because of the 17 months support period for the prior major, the new major is released on the 2nd to latest PHP version, just as in option 1.

Option 4

Switch to a 3 year cycle, but do 2 bumps that year:

  • Release Drupal 10.0 in June 2022 with a PHP 8.0 minimum and on Symfony 5.4.
  • Release Drupal 11.1 in Dec. 2022 with a PHP 8.1 minimum and on Symfony 6. Keep supporting Drupal 10 until Nov 2024.
  • Release Drupal 12.0 in June 2025 with a PHP 8.3 minimum and on Symfony 6.4. Keep supporting Drupal 11 until Nov. 2026.
  • Release Drupal 13.1 in Dec 2025 with a PHP 8.4 minimum and on Symfony 7. Keep supporting Drupal 12 until Nov. 2027.
  • Release Drupal 14.0 in June 2028 with a PHP 8.6 minimum and on Symfony 8.4. Keep supporting Drupal 13 until Nov. 2029.
  • Release Drupal 15.1 in December 2028 with a PHP 8.7 minimum and on Symfony 9. Keep supporting Drupal 14 until Nov. 2030.

This is the most complicated option. However, the odd-numbered major version (the ones in December) would only bump the PHP version and the Symfony version. Everything else, like Drupal's own deprecation removals as well as all dependencies other than Symfony would get bumped in only the even-numbered (June release) version. And the Symfony X.4 versions have everything that's in the (X+1).0 version, so being simultaneously compatible with e.g., 5.4 and 6.0 is easy. In other words, every 3 years when contrib needs to update, it could update once as early as June (or even ahead of June if it wants to track to Drupal's beta or RC), and in that one update declare a compatibility on ^10 || ^11 (or whatever the appropriate even and odd versions are), and not need to do any new work when the December release comes.

Remaining tasks

Discuss the pros and cons of each option, or suggest other options. I'm the most partial to Option 4, despite its difficulty to explain, because it gives contrib maintainers and site owners 3 years between upgrades instead of 2 years, but still lets core developers use newer PHP features on a reasonable schedule.

User interface changes

API changes

Data model changes

Release notes snippet

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave at Full Fat Things commented

I think option 4 is confusing to explain and will be a difficult sell to end users, for example they upgrade to Drupal 10 and six months later Drupal 11 comes out. Every other software product on a regular release cycle can be measured easily in years or weeks, I don't know of anything with an irregular cycle like this. Also, is PHP really gaining that many must-have features that we need to be keeping up with it? Symfony won't be bumping PHP versions as often as we do, so I don't see what we gain from trying to go faster here.

Personally I feel that option 2 is the most attractive. A two-year cycle is easy to understand and matches Symfony. A 29 month support window lets sites, if they choose to do so, only upgrade once every four years - they would have five months to jump from Drupal 10 to Drupal 12. Neither option 1 nor 3 allow this flexibility, having a forced upgrade either on either a two or three year cycle. The downside is more work for core committers and release managers, as security issues and critical bugs have to be backported across three majors for that five month window.

Option 3 also means we run into #3196027: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4 which so far we haven't solved for the 4 > 6 upgrade, and we can't know how this will go in advance - it really depends on how many breaking changes follow the skipped version as to how difficult this will be.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented

A 29 month support window lets sites, if they choose to do so, only upgrade once every four years - they would have five months to jump from Drupal 10 to Drupal 12.

I'll update the IS with a more detailed list of pros/cons when I have a moment, but in the meantime, another benefit of option 2 is it would let sites upgrade every 2 years, but always be on an LTS track. In other words, they could go from 10.4 to 11.4 to 12.4. Some benefits of this is it maximizes how much of contrib is available and stable when it's time to do the major upgrade, and then the site can spend 2 years not doing any minor core updates.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Issue summary: View changes

Slightly edited option #2:

Keep the same 2 year cycle, but switch to 29 months of continued support for the prior version

I've changed this to up to 29 months of support for a couple of reasons:

1. We might want to make it 24 months or 27 months to fit into the rest of the release cycle (i.e. EOL ends when the new LTS comes out, or + a 3 month grace period).
2. We might have other dependencies (other than Symfony) with earlier EOL dates, and we might not know about that five years in advance.
3. We need to be able to accommodate a couple of months shift in the PHP and Symfony release cycles which aren't guaranteed to continue on exactly the same schedule.
4. We could always add a couple of months of extra LTS support to a release that needs it, but taking two months away would be bad. We could also stagger the LTS and major releases if we have everything in place - i.e. the LTS release three months earlier than the new major, to give LTS-to-LTS sites the longest possible window. (This is only possible if we have less to do to get the final LTS out, but that might be the case on a two year cycle).

Also added Symfony versions to option #1 or option #2, although if these aren't what you intended please correct them.

For me personally, I prefer option #2 here - it's very predictable and easy to understand. New sites are able to use the latest PHP and Symfony APIs almost as soon as they're available and get the longest possible support period, older sites can go LTS-to-LTS if they want to. A two year cycle means less churn between majors, which means smaller batches of deprecations and dependency updates, making the major releases closer to a minor than they currently are.

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle as a volunteer commented

+1 on option #2
If Drupal will use the Symfony framework then we should have a similar release cycle, and possibly use the latest version of Symfony.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Status: Active » Closed (cannot reproduce)

After having written this up and reading the comments (thank you all!), I can't really make a good case for options 1, 3, or 4. Therefore, closing this as outdated in favor of #3238652: [policy] Decide how long major Drupal versions should be supported.

We might want to make it 24 months or 27 months to fit into the rest of the release cycle (i.e. EOL ends when the new LTS comes out, or + a 3 month grace period).

I disagree with this. I think it would be much more valuable to site owners to know what the minimum overlap period is way ahead of time. So I wrote up #3238652: [policy] Decide how long major Drupal versions should be supported based on committing to 3 months, but of course, we can debate and change that there as needed.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Status: Closed (cannot reproduce) » Closed (outdated)

I meant for the status to be "outdated", not "cannot reproduce", so fixing that.