Continuing a conversation that already exists. The specific phrasing (“align Symfony LTS with even-numbered Drupal majors”) has been discussed #3508715: [policy, no-patch] EoL for majors six months after the release of the second subsequent major .
Currently it is Drupal 10.
It appears that Drupal 12 will possibly be landing with an LTS release of symfony. Is this a coincidence or by design? There currently is no official policy on alignment with symfony LTS. Are we able to predict whether or not Drupal 14 will also land with an LTS release of symfony?
For predictability and planning purposes of our stakeholders we would like:
[Policy] - Align even numbered majors to LTS releases of symfony.
Agree on policy, adjust release schedule for majors.
| Comment | File | Size | Author |
|---|---|---|---|
| symfony_release_cycle.png | 11.17 KB | joseph.olstad |
Comments
Comment #2
joseph.olstadComment #3
longwaveBefore we could do this we would need confirmation from Symfony of which versions will be LTS, before we even release a version of Drupal that uses it; can you link to any Symfony policy statements where this has been announced? If not, I don't see how we can promise anything up front.
Comment #4
joseph.olstad@longwave , Symfony is the egg, and Drupal is the chicken. We’re the farmers raising those chickens.
We already know ahead of time when the LTS egg will be laid — Symfony’s predictable pattern makes that clear. As soon as we know which Symfony egg is going to be an LTS, that’s when we should decide what kind of Drupal chicken we’re going to raise and call it a hen (the even-numbered major).
Since Drupal 8, we can’t hatch a Drupal chicken without a Symfony egg. Some of those eggs are LTS, and we have customers who specifically want those dependable, long-lived hens.
We effectively have two kinds of Drupal chickens — hens (even-numbered, LTS-aligned) and roosters (odd-numbered). Both are useful, but we should be transparent about which is which so site owners can plan their farms accordingly.
Comment #5
joseph.olstad@longwave
Symfony actually does publish a predictable release cadence and LTS policy on their official releases page: https://symfony.com/releases
.
They’ve consistently followed the same pattern for more than a decade:
So while Symfony doesn’t publish a 15-year forward schedule, its LTS pattern is well established and predictable.
In comparison, Drupal’s own major release dates (e.g., Drupal 12 in June 2026) are targets that often shift, so expecting Symfony to give stronger future guarantees than Drupal itself provides seems disproportionate.
Drupal requires symfony, symfony does not require Drupal.
Knowing that every even-numbered .4 is an LTS is sufficient to plan alignment confidently — e.g.,
and so on and so forth.
Comment #6
joseph.olstadComment #7
joseph.olstadComment #8
longwave> Every even-numbered .4 release is designated as an LTS.
Where does it say this? On the contrary it appears they call every .4 release an LTS?
And this still makes little difference to Drupal:
Drupal 10 will be EOL in December 2026. Symfony 6.4 will be EOL in November 2027.
We haven't announced an exact date yet but Drupal 11 is likely to be EOL in December 2028. Symfony 7.4 will be EOL in November 2029.
Drupal 12 dates haven't been confirmed, but neither has an end date been set for Symfony 8. We did however announce that D12 will release in 2026 and therefore it will be on Symfony 8; your suggestion that Drupal 12 uses Symfony 7.4 makes us worse off, because as stated above that will be EOL in November 2029.
Even if we extended for another eleven months to meet Symfony, we also have to consider our other dependencies such as CKEditor, who won't or can't necessarily make the same promises as Symfony.
This is all information that hasn't changed since the last issue where you asked for the EOL to be extended, so I'm not sure of the point of rehashing it all again here; you will get the same answer.
Comment #9
joseph.olstadSymfony’s official releases page doesn’t explicitly say “every even-numbered .4 release is LTS,” but in practice every
.4release has been designated LTS since Symfony 2.4 (2013).The pattern has held consistently for over a decade:
It’s about giving the ecosystem a clear signal —
“Drupal 14, 16, 18 → Symfony 9.4, 10.4, 11.4 (LTS)” —
so developers and clients can better understand the scope of upgrades confidently years in advance.
That level of predictability doesn’t require 15-year commitments from Symfony; their 10-year pattern is already reliable enough to anchor a Drupal policy statement.
Comment #10
xjm@joseph.olstad, I believe you're overlooking an advantage of the current practice, which is that it allows us longer support lifetimes for core versions without needing to change Symfony major version requirements in the middle of a core major version. We did this once in Drupal 8 (upgrading from Symfony 2 to Symfony 3) and it was extraordinarily disruptive.
To change now, we would have to sacrifice other things you and other site owners want, like a predictable schedule, or a Drupal 10 support lifetime that extends to at least the release of Drupal 12, or a guaranteed specific EOL date for Drupal 12 in December 2026 rather than an upredictable one that could be in June or August or December, or a guaranteed minimum 4 years of support for every Drupal major version.
The important thing from our perspective is that our maintenance minors land on LTS versions of Symfony, so that these LTS-like versions of Drupal have the increased stability offered by the LTSes of Symfony. So Drupal 10.3 and above are on Symfony 6.4, and Drupal 11.4 and above will be guaranteed to be on Symfony 7.4, and the maintenance minors of Drupal 12 (whatever their specific version numbers) will be on Symfony 8.4.
Drupal 12.0 will release with the latest version of Symfony 8 available at the time of its release. That will probably be Symfony 8.1 if it is released in June or August 2026, and Symfony 8.2 if it released in December 2026. However, the maintenance minors during Drupal 12's LTS phase will be on Symfony 8.4. If Symfony keeps their same release schedule in subsequent years (which we hope, but cannot guarantee), then Drupal 13.0 will be on Symfony 9.1 if it is released in June or August 2028, and Symfony 9.2 if it is released in December 2028, but the maintenance minors of Drupal 12 will be on Symfony 9.4.
We need the 6-month lead time after a new Symfony major release to make core compatible; it's part of why we have the major release schedule we do in the first place. However, adopting as early as we can maximizes the length of time we can support each Drupal major. To change from that, we'd have to shorten the support lifetimes of major versions of Drupal. I'm sure that's not what you want.
For me this issue is "Works as designed".
Comment #11
joseph.olstadOk, I'm seeing it now, so DXX.3+ where we focus on the
.3+ is really the stable offering that certain clients may want to plan their upgrades for. These ones are on or soon to be on LTS versions of symfony. Earlier DXX minors are like the early adopters of the next Symfony major. Ok so while it may not always be a DXX.3 it'll be close to or the next one that gets the Symfony LTS.We're getting a better understanding of the timelines here.
Ya feel free to close this. My questions are answered. It's not so much the major but the Drupal minor that gets the symfony LTS.
Thanks.
Comment #12
joseph.olstadI'll say cannot reproduce since it's actually the minors on or after
.3that are more aligned to Symfony LTS and NOT the majors. The majors are NOT aligned to symfony LTS and I think it makes more sense that the minors are (for now, unless the symfony lifecycle changes dramatically)Comment #14
quietone commented@joseph.olstad, thanks for closing this.
Talked about this with xjm in Slack and we agreed that, due to the importance of Symfony to Drupal, an item can be added to the Maintenance minors and the LTS phase of the Release Process Overview page. The addition just states that Drupal LTS uses a Symfony LTS.