I'll say cannot reproduce since it's actually the minors on or after .3 that are more aligned to Symfony LTS and NOT the majors.
Ok, 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 major.
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.
Symfony’s official releases page
doesn’t explicitly say “every even-numbered .4 release is LTS,” but in practice every .4 release has been designated LTS since Symfony 2.4 (2013).
The pattern has held consistently for over a decade:
Symfony version Release year LTS EOL
2.4 / 2.8 2013–2015 ✅ yes
3.4 2017 ✅ yes
4.4 2019 ✅ yes
5.4 2021 ✅ Nov 2025
6.4 2023 ✅ Nov 2027
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.
@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:
- Every even-numbered .4 release is designated as an LTS.
- This pattern has held since Symfony 2.4 → 2.8 → 3.4 → 4.4 → 5.4 → 6.4 → and the upcoming 8.4 LTS (with 9.4, 10.4, 11.4 also planned as LTS).
- The cadence is every 2 years, with .4 being the final minor in each major’s cycle.
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.
Knowing that every even-numbered .4 is an LTS is sufficient to plan alignment confidently — e.g., Drupal 10 → Symfony 6.4 LTS, Drupal 12 → Symfony 8.4 LTS, and so on.
@longwave , Symfony is the egg, and Drupal is the chicken. We're the farmers raising chickens. When the LTS chic is born, that's when we should name the that chicken a hen. We decided that we need the symfony egg to make our Drupal chickens. We can't have Drupal chickens without eggs. Some of these eggs are LTS and when they are born, we have customers that want to know that they will be called hens.
We have two types of Drupal chickens, hens and roosters. Some of our clients will buy the Drupal roosters, others want only Drupal hens.
@mp, still waiting for your patch, that's what is holding this up.
🌱 [policy] align Symfony LTS with even numbered Drupal majors Postponed: needs info
Hopefully we can solve this issue soon and review to ensure that it works for everyone.
ok wow, I'll back off the change for now until this issue gets resolved, thanks for reporting!
Merge train is running now, it'll be merged shortly, this will go into a release shortly after.
I have no access to Slack so I sent a message to Hestenet about this.
Still needs work.
We do now have some automated test coverage so that should help here.
last assertion fails but manual testing shows it's actually good.
Commented out last assertion for now, fix the test later.
joseph.olstad → made their first commit to this issue’s fork.
joseph.olstad → made their first commit to this issue’s fork.
@gwvoigt , if you provided the markup for the two elements there, could fix it.
Developers home in eastern Ukraine was destroyed by invading neighbor. We have 100% proof of this. I support the Drupal developer. Every Drupal developer needs a safe home to do development work.
Fixed in 4.0 releases
Please use current 4.1.1+ which supports both Drupal 10 and Drupal 11.
Huge thanks to @pobster , excellent work!
commit 2308772d is a kludge but might help some folks and get the discussion and ideas rolling.
joseph.olstad → made their first commit to this issue’s fork.
I see a whole plethora of new issues, sounds like significant changes, may I suggest creating a 2.0.x branch and merging these into the then new 2.0.x branch?