As you may know, we are planning to release Drupal 10 in 2022 (as early as June), because Drupal 9's Symfony 4 and CKEditor 4 are both end of life the year after, around the end of 2023. So we plan go give enough time for people to update to Drupal 10 before Drupal 9 goes end of life. A similar situation happened with Drupal 8 to 9 driven by Symfony 3 to 4. However, moving Drupal 10 from Symfony 4 to 5 would again only give us a couple years of time to move on to Symfony 6 next, so the current plan is to move to Symfony 6 straight.

How is it possible to move Drupal 10 from Symfony 4 to 6? Symfony 6.0 was just released a few hours ago and is stable, so by the time Drupal 10 would be released, it will already be at least on Symfony 6.1.

However, the exact same thing happened with Drupal 8, and we did not do a double Symfony version jump update from Drupal 8 to 9 for two reasons: (a) even though Drupal core minor versions are supported for 12 months, Symfony minor versions are only supported for 8 months other than the last LTS minor version and (b) jumping two versions would mean that scanning for and acting on minor version to minor version all deprecations is challenging. Those two did not resolve themselves so to speak, however we have plans to mitigate them.

Symfony security extension for Drupal-used packages

First of all, Symfony normally supports minor releases for 8 months starting with Symfony 5. On the other hand Drupal minor releases are supported for 12 months, so if there are security fixes to be made, this would not be possible on a non-LTS version of Symfony. However we made arrangements with the Symfony team to have two of the Drupal core committers be part of the Symfony security process and be able to backport security fixes as needed for components used by Drupal even if the given Symfony minor version would be normally out of support. The two Drupal core committers involved are Alex Pott and Lee Rowlands! I don't believe there was an official announcement of this agreement yet, however it was in place since September 2019. Special thanks for the open minded collaboration of the Symfony leads as well!

Bridging the deprecations jump with Symfony 5.4

Second is bridging API deprecations. Nathaniel Catchpole outlined the plan for this recently. The problem is that Symfony 4 deprecated some APIs for removal/changes in Symfony 5 and them Symfony 5 deprecated some APIs for removal/changes in Symfony 6. Jumping through two versions gives Drupal 10 a potentially longer lifetime but with a need to solve identifying all deprecated API uses for both. Now that both Symfony 5.4 and 6.0 are out, the plan is to open the Drupal 10.x-dev branch for development very soon and update to Symfony 5.4 as well as other big dependency updates. Then release a Drupal 10.0.0-alpha1 that is based off of Symfony 5.4, which would allow contributed projects and custom code to check against deprecated APIs towards Symfony 6. And only later update to Symfony 6. This way there is a middle-point that allows to make the necessary updates and check deprecated APIs against.

As jumping two major Symfony versions is not something we did before, let us know in the Drupal 10 issue if you can poke holes at the grand plan. While it looks like this will be entirely possible, it would be best to find any potential pain points ahead of Drupal implementers hitting them.

A proposal with overlapping LTS release versions of Drupal core

Lee Rowlans went even further and presented the potential benefits of this plan down the line with Drupal 11 and Drupal 12. Releasing Drupal 10 on Symfony 6 would allow us to support it longer, up to November 2027. However it does not mean that we cannot release Drupal 11 earlier than 2026 let's say. Releasing earlier would allow us to jump faster to Symfony 7 while it would still give Drupal 10 users a more comfortable, longer support timeline. Check out this video where Lee explains the details and discuss in the issue titled Adopt a 2 year major release cadence and a 6 month LTS-to-LTS overlap period for Drupal 10 and beyond. (This is not yet a firm policy, it is under discussion).