[policy no-patch] Discuss LTS options

@Joseph Olstad

, I see an opportunity to establish a deliberate policy to align with Symfony LTS versions wherever possible—not just reactively shift to the latest stable version available at the time of release.

That has already been done - we release new major versions as close to the *.1 version of a new Symfony major version as we can, in order to then have the longest possible run until the EOL. So once again it does not seem that you've read any of the current policies or previous discussions around this.

Hi Catch,

I appreciate the clarification that Drupal 10 and Drupal 11 were planned to maximize the support window for Symfony 6.4 and 7.4. That is an improvement over past decisions with Drupal 8 and 9, and it’s great to see more deliberate planning in this regard.

However, my concern—and the reason for raising this discussion—is that aligning Drupal’s release cycle with Symfony’s standard major versions still does not fully address the core issue of long-term support across the ecosystem.

Why this discussion still matters

1. Symfony’s LTS model is designed around the enterprise ecosystem, yet Drupal is not explicitly prioritizing Symfony LTS versions in its release planning.
   • While Symfony 7.4 is a long-lived release, it is not an LTS version in the same way Symfony 5.4 was (which had security fixes for 5 years).
   • Would it make sense to formally adopt a policy that Drupal only targets Symfony LTS versions (whenever possible) rather than relying on whichever major version is available at the time?
   • This would ensure that Drupal major versions align with the longest possible security support windows, reducing unnecessary migrations.
2. Other critical dependencies (PHP, Twig, Doctrine, Packagist) are not necessarily following an LTS-friendly model
   • Even if Drupal aligns with Symfony’s longest-lived major releases, PHP does not currently have an equivalent LTS strategy, meaning Drupal can end up in situations where the underlying PHP version reaches EOL mid-lifecycle. (The alternative is third party vendors like Red Hat that support PHP release far past the 4 year expiry date of zend however if we can convince PHP leadership to extend it's cycle to 5 years that would be even better
   • Many packages in the PHP ecosystem do not offer extended support, and Drupal inherits these unstable upgrade cycles, forcing churn.
   • How can we engage with PHP and other maintainers to encourage better LTS support across the broader ecosystem?
3. The need for a holistic LTS policy that spans the entire Drupal ecosystem
   • A long-term support strategy for Drupal isn’t just about core—it also affects contrib maintainers, hosting providers, and enterprise adopters.
   • If core moves forward on a more stable, LTS-friendly path, it could create ripple effects across the ecosystem, benefiting thousands of Drupal projects.
   • Many competing platforms (WordPress, Django, even Ubuntu LTS) provide more predictable upgrade paths, making them easier to maintain in the long run.

Proposal: A Formal Drupal LTS Policy

Instead of making case-by-case versioning decisions, would Drupal leadership be open to a formalized LTS policy that:

• Prioritizes Symfony LTS versions when choosing major upgrades (whenever available).
• Advocates for a PHP LTS model that extends beyond the current 4-year window, working with PHP maintainers and enterprise vendors.
• Engages with key Packagist maintainers to promote better long-term support strategies for dependencies.
• Explores structured LTS releases for Drupal itself, where both LTS and standard releases exist (similar to Ubuntu).

I understand that past discussions have taken place about how Drupal selects Symfony versions, but the broader LTS conversation—spanning PHP, Symfony, and Packagist as a whole—still needs to be addressed.

Would it be worth having a deeper discussion about what a Drupal-wide LTS strategy would look like across all dependencies rather than just Symfony alone?

Best,
Joseph Olstad

it is not an LTS version in the same way Symfony 5.4 was (which had security fixes for 5 years).

Again this is not true, you are making unsupported assertions that aren't based in fact, repeatedly, for multiple different claims. Every time I correct one of them you make a different one.

Symfony 5.4's EOL was extended in October 2024 due to a commercial agreement between Ibexa and Sensiolabs (or the Symfony subsidiary of Sensiolabs, no idea how it's structured). It was announced here https://symfony.com/blog/symfony-5-4-lts-will-receive-security-fixes-unt.... Prior to October 2024, Symfony 5.4 had the same support cycle as any other Symfony major release.

There is no equivalent commercial agreement in place for Symfony 6 or 7, both of which have 5 year support cycles as advertised. Drupal core is not a company and cannot make commercial agreements, even if we wanted to.

Hi Catch,

Thanks for the clarification regarding Symfony 5.4’s extended support coming from a commercial agreement rather than an inherent policy decision by Symfony itself. That’s an important distinction.

However, this raises a key strategic question for Drupal:

Why isn’t Drupal aligning itself with commercial LTS agreements for Symfony and other dependencies?

• If Ibexa and SensioLabs can fund extended support for Symfony LTS, why wouldn’t Drupal—a widely adopted CMS powering enterprise and government websites—consider a similar approach?
• The Drupal Association already raises funds to support initiatives like security, marketing, and innovation. If ensuring long-term stability for core dependencies requires financial backing, is this something we should be proactively working toward?
• Companies and governments using Drupal already invest significant resources into maintaining Drupal and dealing with forced upgrades. Wouldn’t it be more cost-effective for Drupal as a whole to negotiate commercial LTS agreements rather than forcing each organization to navigate these transitions independently?

A Proposal: Exploring Drupal-Funded LTS for Symfony & Dependencies

Since Drupal depends heavily on Symfony, PHP, and Packagist libraries:

1. Can the Drupal Association explore a funding model to participate in commercial LTS agreements?
   • A GoFundMe-style initiative (or structured Drupal Association sponsorship) could allow the community and enterprise users to collectively fund extended Symfony LTS support.
   • If funding were secured, could Drupal negotiate Symfony LTS extensions for future versions?
2. Could Drupal work alongside other open-source projects (e.g., TYPO3, Laravel, Ibexa) to collaboratively fund Symfony LTS?
   • Many major PHP projects use Symfony components—is there an opportunity to coordinate cross-project LTS efforts?
3. Would Drupal enterprises be willing to contribute to extended LTS funding if it meant a more predictable upgrade path?
   • This could significantly reduce the cost of forced migrations for businesses that rely on Drupal’s stability.

Regarding “demonstrating a flaw and solution” for Symfony before discussing other dependencies

The flaw isn’t whether Symfony 6/7 has a 5-year lifecycle—it’s that Drupal lacks an active strategy to secure long-term support for Symfony or PHP beyond what is provided by default. Other projects (like Ibexa) have taken a proactive stance to secure additional LTS support, while Drupal has remained reactive.

If the only missing ingredient is funding, then the logical step is to discuss how Drupal can join, negotiate, or independently fund an LTS program for Symfony and PHP.

Would Drupal leadership be open to discussing funding models for securing extended LTS, similar to what Ibexa and SensioLabs have done?

Best,
Joseph Olstad

Are you using AI to generate these comments?

Hi Nixvan,

Before diving into the substance of this discussion, I want to acknowledge something on a personal level. Having been an active contributor in the Drupal ecosystem for 14 years, watching major versions come and go since Drupal 6, I’ve seen firsthand the challenges that come with balancing progress and stability.

I’ll be honest—this conversation is frustrating. The current strategy feels insufficient to me, and it’s difficult not to feel a deep sense of urgency about ensuring Drupal has a sustainable long-term future. However, I also recognize that productive discussions require us to step back from emotion, focus on the facts, and work collaboratively toward a solution.

This isn't about assigning blame or dwelling on past decisions—it’s about ensuring that Drupal evolves in a way that serves its users, contributors, and long-term adopters in the best way possible. With that in mind, I want to approach this with professionalism and clarity, outlining why I believe a more concerted LTS strategy is essential and timely.

I appreciate the link to the Drupal release process overview, and I’ve reviewed it alongside the broader Drupal Core Strategy for 2025-2028. While the current strategy extends support for major versions, it does not sufficiently address alignment with commercial LTS agreements, nor does it explore the feasibility of securing extended support for key dependencies (Symfony, PHP, Twig, Doctrine, etc.).

The Core Issue Remains Unaddressed

Drupal’s current release cycle policy does not align with commercial LTS agreements, which means:

• Drupal is forced into a dependency upgrade treadmill rather than having the option to extend support for existing versions if needed.
• Other open-source projects (e.g., Ibexa) have demonstrated that commercial LTS agreements can be secured for Symfony, yet Drupal has apparently not yet engaged in similar discussions.
• Governments, enterprises, and long-term Drupal adopters often require extended stability beyond the default support cycles of our dependencies.

This Is a Strategic Question, Not Just a Versioning Discussion

The question is not whether Drupal’s release process is documented—it’s whether Drupal is taking proactive steps to secure long-term stability in a way that is sustainable for large-scale users.

I’m asking if Drupal leadership is open to:

1. Exploring funding models for LTS – Would the Drupal Association or enterprise contributors be willing to fund extended support for Symfony LTS, similar to how Ibexa/Sensiolabs structured their agreement?
2. Engaging with Symfony leadership – Has Drupal ever formally discussed LTS funding opportunities with Symfony maintainers/leaders to determine feasibility?
3. Aligning with other PHP projects – Are there opportunities to collaborate with TYPO3, Laravel, or other frameworks that share similar dependencies and long-term support needs?

This is not about restating past points—it’s about determining whether Drupal has the ability and willingness to take control of its own long-term support strategy, rather than always being dictated by external dependencies.

Would the core committers be open to discussing these points in a dedicated meeting or structured discussion?

Best,
Joseph Olstad

I am perplexed...

I’m adding 🌱 [12.x] [meta] Release Drupal 12 in 2026 Active as a related issue because any long-term support (LTS) strategy discussions must be considered within the broader planning for Drupal 12.

Drupal 12 is still in its early planning stages, and if we are serious about addressing dependency churn, alignment with commercial LTS agreements, and ensuring long-term platform stability, then these discussions need to happen before the 12.x branch is finalized.

Relevance to Drupal 12 Planning:

1. Dependency Alignment for Drupal 12
   • The meta issue tracks compatibility work for major and minor dependency versions in Drupal 11 to prepare for 12.
   • The discussion on LTS strategy should directly inform which Symfony, PHP, and Packagist dependencies are targeted for Drupal 12, prioritizing long-term stability over short-term upgrades.
2. Setting Platform Requirements for 12.x
   • The issue outlines setting platform requirements at least 6 months before release—an ideal window to solidify an LTS-friendly approach.
   • If we aim to align with Symfony, PHP, and other dependencies in a deliberate LTS-first way, that decision must be reflected before the first alpha release of Drupal 12.
3. Opportunity to Advocate for a Formal LTS Policy Before It's Too Late
   • By linking these discussions, we ensure that LTS strategy is not an afterthought but a fundamental part of Drupal 12’s release planning.
   • This helps reduce last-minute adjustments and provides a structured framework for maintainers to consider enterprise adoption, contrib module support, and long-term ecosystem stability.

Given that Drupal 12’s core policies are not yet finalized, this is the best possible time to ensure that LTS considerations are part of the roadmap. I encourage leadership and maintainers to review these discussions in the context of the broader Drupal 12 release cycle so we can align on a strategy that minimizes upgrade churn and improves long-term maintainability.

I've updated the issue summary to provide a clearer and more structured framework for establishing an LTS strategy for Drupal. The updated summary:

• Clearly defines the problem statement and why Drupal needs a long-term support strategy.
• Outlines proposed actions for aligning Drupal with Symfony LTS, PHP stability, and Packagist dependencies.
• Emphasizes the importance of incorporating LTS discussions into 🌱 [12.x] [meta] Release Drupal 12 in 2026 Active .
• Identifies key stakeholders and decision-makers who should be involved.
• Includes concrete next steps for forming a working group and securing discussions with Symfony/PHP maintainers.

Would love feedback from the community and core maintainers on the next steps for formalizing this approach!

Posted this in the other issue, but PHP is far from being overtaken by Python. https://w3techs.com/technologies/comparison/pl-php,pl-python

I don't care what GitHub states, not everyone uses it (I sure as hell don't) and hobby projects that are hosted there skew the results vs actual client projects that are hosted on private repositories. We run our own GitLab and I'm sure many agencies do the same.

Also what's up with the AI-like comments? Please follow the issue etiquette if you are using AI generated responses, which it looks like you are: https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →

Exploring funding models for LTS – Would the Drupal Association or enterprise contributors be willing to fund extended support for Symfony LTS, similar to how Ibexa/Sensiolabs structured their agreement?
Engaging with Symfony leadership – Has Drupal ever formally discussed LTS funding opportunities with Symfony maintainers/leaders to determine feasibility?

The Drupal Association currently does not fund Drupal core committers or other maintainers, or the security team. Obviously it funds gitlab and other infrastructure that is necessary for core development, but there is no funding of the development itself. Some core committers have funding from their employers, several do not. So frankly the idea that the DA should fund Drupal's dependencies instead is baffling to me.

lign Drupal with Symfony LTS versions – Future Drupal releases should proactively choose Symfony LTS instead of rolling with short-lived versions.

This and many other statements in the issue summary are still completely false, I'm starting think this is deliberate because you are continuing to state these despite multiple corrections.

I don't care what GitHub states, not everyone uses it (I sure as hell don't) and hobby projects that are hosted there skew the results vs actual client projects that are hosted on private repositories. We run our own GitLab and I'm sure many agencies do the same.

Yes and it's not just about personal vs. professional codebases. Python is used in a lot of non-web applications (neuroscience stats analysis for example), so while you can use it for web applications, you can't just look at the github stats and say it's taking off for web applications.

Hi kristiaanvandeneynde,

Thanks for your perspective. While the W3Techs data shows PHP remains dominant in web hosting, the concern I raised is about **long-term trends** in developer adoption and ecosystem growth. GitHub’s statistics provide insight into **new and active development projects**, particularly for open-source contributions.

However, rather than debating PHP vs. Python usage, the real question is: **How does Drupal position itself for long-term sustainability in a rapidly evolving tech ecosystem?**

The goal of this issue is to address dependency churn and establish an LTS strategy that allows Drupal to be a **stable and predictable choice for enterprises, governments, and developers**. This remains true regardless of PHP’s broader market position.

Would you agree that minimizing disruptive upgrades is a valid goal for Drupal’s long-term roadmap? If so, what improvements would you suggest to make an LTS model feasible?

• Two people have asked to clarify whether you're using AI. No answer.
• Two people have pointed out flaws in the premise of your argument. Flaws ignored and another wall of text commented.

This isn't constructive, going to postpone until we get clarification on the use of AI.

The reality is that many enterprises, governments, and large-scale adopters of Drupal need long-term stability to build sustainable solutions. If these organizations are constantly forced into disruptive upgrades because of dependency churn, then they spend more time migrating than innovating.

Why LTS Doesn’t Mean Slowing Down

• Allows teams to focus on innovation – Instead of spending resources upgrading dependencies every 2-3 years, developers can focus on building new features.
• Reduces upgrade fatigue – Frequent forced upgrades don’t always lead to meaningful innovation; they often just cause compatibility headaches.

Many modern projects have LTS models – Symfony itself offers LTS versions without being a "dying technology." Ubuntu, Node.js, and Laravel all have structured LTS models that support agility without excessive churn.
Flexibility for those who want faster iterations – LTS does not mean everyone has to use it. Many ecosystems (e.g., Ubuntu, Laravel) provide both LTS and non-LTS versions to serve different needs.
The question isn't whether Drupal should "slow down"—it's whether we should intelligently manage our release cycles so that we don’t burn developers and adopters out with frequent disruptive upgrades.

I appreciate the engagement in this discussion, and I fully respect that others experience with Drupal’s release cycles has been positive. Many have a well-managed CI/CD pipeline and a workflow that allows you to upgrade quickly and efficiently, which is fantastic.

However, the reality is that not all Drupal users—especially those in government, large enterprises, or highly regulated industries—have that same flexibility. Many organizations cannot adopt the latest versions at the same speed or level of effort due to compliance, security, procurement, and internal governance processes. That doesn’t mean they aren’t “strong” contributors to the ecosystem; it simply means they have different needs.

This is About Flexibility, Not Slowing Drupal Down

• An LTS model would not replace the current release cycle—it would provide an option for those who need longer stability.
• Faster adopters (like yourself) can continue innovating at full speed, while others can opt for an LTS version without being forced into disruptive upgrades.
• Many modern software ecosystems balance LTS & non-LTS versions (Symfony, Ubuntu, Node.js, Laravel) to serve both types of users.

For example, Symfony offers both LTS and non-LTS releases. This does not prevent developers from adopting new versions quickly, but it ensures that **those who require longer stability have a structured support model**.

Who Benefits from LTS?

• Enterprise users and governments—who have strict compliance policies and long procurement cycles.
• Drupal contributors maintaining complex distributions—where rebuilding every 2-3 years is a major effort.
• Developers who want to focus on feature innovation—rather than repeatedly upgrading dependencies.

We do not have to force **everyone** onto an LTS path—lets offer a solution that ensures Drupal is viable for more stakeholders in the long run.

An LTS model could coexist with the current rapid innovation cycle so that Drupal serves both groups effectively

Hi Kristiaan,

The purpose of this issue is to **discuss an LTS strategy for Drupal**, not to debate the formatting or writing style of comments. If there are specific flaws in the proposal, I welcome **concrete feedback** so we can refine and improve it together.

However, postponing the issue based on speculation rather than engaging with the core discussion **does not move the conversation forward**.

Key Unanswered Questions:

• Should Drupal offer an LTS option for those who need longer stability, like Symfony and other major projects do?
• Could an LTS strategy coexist with the current release cycle without slowing innovation?
• What mechanisms could help reduce upgrade fatigue for enterprise/government adopters?

These are real concerns from long-time Drupal contributors and enterprise users. If you disagree with the premise of the discussion, I encourage you to provide specific **counterarguments based on facts and reasoning** rather than attempting to sideline the discussion.

@joseph.olstad as you invited me to join this discussion and as this seems to be stuck in your mindset that updates are disruptive by your definition, I have to follow your invitation to also let you know in public, that I disagree.

Upgrades have never been as smooth as they are today. And that's because the Drupal community was willing to innovate so fastly. I'm saying that as a maintainer of around 70 contrib modules, some of which being pretty complex. And my agency is working on complex customer projects almost exclusively. You're not alone in that "battle field". And yes, new tools and new possibilities in Drupal, Symfony, PHP and other components forced us to sometimes heavily re-engineer customer solutions. And we've always done so, often times maybe even too early.

I know the problem with government customers. And getting yourself out of the limitations that distributions bring with them, is a real issue. I appreciate that, but to assume that LTS would make this issue any smaller is a dream that will never come true. Not because LTS wouldn't be possible, it's because LTS would just delay the process to get the re-engineering of your client projects done.

That said, I strongly believe that this discussion is the wrong one. It seems to be driven by issues with customer inertia, and your proposal may resolve that for now. But the problem would stay around and won't get any less painful, just that all stakeholders would feel that pain for a much longer period of time.

Maybe you can find help in getting out of the mess with those client projects instead of continuing this discussion? Might be more successful and satisfying.

Hi Catch,

Thanks for your response. I understand that the Drupal Association does not currently fund core maintainers or security teams directly, nor does it fund external dependencies like Symfony. That’s not in dispute. However, the question here is not about diverting existing funds, but rather: Should Drupal explore alternative funding models to improve long-term stability?

Funding Discussion – Why Is It "Baffling" to Explore?

• Other open-source projects have successfully structured LTS funding agreements, such as Symfony 5.4’s extended security support via Ibexa and Sensiolabs.
• Enterprise stakeholders already invest heavily in maintaining long-lived Drupal projects—could an LTS sponsorship model reduce the overall maintenance burden?
• If there’s no immediate path for funding today, would it be worth discussing this with the DA and enterprise partners?

Clarification on "False" Claims:

You mentioned that several statements in the issue summary are “completely false” and implied that these claims are being made deliberately. If something is incorrect, I’d be happy to adjust the wording. Could you specify exactly what statements are inaccurate and why?

As far as I understand:

• Drupal does not currently align explicitly with Symfony LTS, but rather follows major versions with no fixed duration.
• There has been no formal discussion on negotiating an LTS agreement for Symfony 8+ in a way similar to Symfony 5.4’s extended support.
• The current release model places a burden on organizations requiring **stability beyond 3-4 years**, which is why an LTS discussion is relevant.

Hi Jurgenhaas,

Thanks for sharing your perspective, and I appreciate that your experience with upgrades has been positive. Your ability to keep up with rapid changes is commendable, and I don’t dispute that for agencies like yours, **fast iteration is a strength**.

However, the reality is that many organizations—especially in **government, enterprise, and regulated industries**—do not have the same flexibility. This discussion is not about resisting change but about ensuring that Drupal remains a viable choice for those who require stability over extended periods.

Clarifying the Purpose of an LTS Strategy

• An LTS option does not prevent innovation—it allows those who need stability to have a supported path, while those who prefer rapid iteration (like your agency) can continue upgrading as frequently as they wish.
• Not all customers can "just re-engineer" their projects—large-scale, multi-stakeholder projects often have compliance, procurement, and budget constraints that do not align with rapid upgrade cycles.
• Delaying disruption is different from avoiding it—a well-planned LTS cycle allows organizations to plan for necessary changes instead of reacting to forced migrations.

Why This Discussion Matters

The assumption that every organization can (or should) adopt upgrades at the same pace ignores the diverse needs of Drupal’s user base. The goal of this discussion is not to argue about whether **you** need LTS, but rather:

• Should those who need longer-term stability have a supported LTS path?
• Would offering an LTS version broaden Drupal’s market appeal to government and enterprise users?
• Could a structured LTS model reduce overall maintenance burden for contributors by allowing more focused upgrades?

This is about options, not resistance to progress. If you feel that an LTS model wouldn’t benefit your workflow, that’s understandable, but should those who **do** need it be denied the option?

Would you be open to discussing how an LTS model could exist alongside the current release cycle rather than replacing it?

I propose a very simple LTS strategy, goes as follows:

• Odd numbered majors would be the non-LTS where it skips to the odd numbered major of Symfony (D13=S9)
• Even numbered majors would be based on an LTS version of Symfony negotiated prior to finalzing the even numbered release. (D12=S8LTS)

This is about options, not resistance to progress. If you feel that an LTS model wouldn’t benefit your workflow, that’s understandable, but should those who **do** need it be denied the option?

It's not me asking for a major change. It's your proposal which comes with a huge cost that we so should carry in favour of your clients that told you that they can't accept otherwise as what they need is stability. Is that the same clients that host a lot of their services with big tech corps that introduce undocumented changes at will?

Extending LTS is asking for a huge burden from all maintainers, core and contrib. Who should be paying for that extra cost? Are those clients willing to take that on?

Hi Jurgenhaas,

I completely agree that LTS comes with a cost, and I appreciate you raising this concern. The goal here is not to impose additional burden on maintainers without support but to explore whether structuring our releases in a way that aligns with Symfony LTS could reduce overall maintenance effort in the long run.

Addressing the Cost Concern:

• Predictability reduces maintenance overhead – By aligning even-numbered Drupal releases with Symfony LTS, maintainers would have a **longer support window** for stable versions, reducing the need for **mid-cycle compatibility patches**.
• Maintaining a stable major is something we've done successfully in the past with Drupal 7 as it was maintained by a handfull of volunteers, mainly mcdruid and poker10 and prior to that mostly DavidRothstein with the community providing the rest of the contributions.
• We're currently discussing only 5 years of LTS rather than Drupal 7s nearly 15 years of support

Big Tech vs. Drupal Stability

Regarding your comparison to big tech providers making undocumented changes—there is a big difference between hosted services controlled by third parties and a **CMS that organizations build their entire digital infrastructure on**.

• When a cloud provider changes an API, organizations **have no choice but to react**.
• With Drupal, **we control our own roadmap**. That means we have the power to create a **long-term stability option** rather than forcing all users onto a 2-4 year major upgrade cycle.

@mcdruid and @poker10 currently no longer have any Drupal 7 related maintenance and security related duties, I'm guessing it will be easy to find and build a highly qualified LTS team.

This is speculating about who could take on the extra work, but not a single word about who is paying for this.

Predictability reduces maintenance overhead

How so of I need to support old code for a longer period of time?

When a cloud provider changes an API, organizations **have no choice

I'm not taking about random cloud providers. It's about e.g. MS Azure that provides business critical services which of so unreliable. And I'm talking about highly regulated clients as well. Of they trek you they can't accept change, they're just taking the shit or of you.

forcing all users onto a 2-4 year major upgrade cycle.

We don't have any major updates any longer. We have incremental updates, even from D10.4 to D11. If you extend LTS from currently 4 to 5 years and only update at the very last minute, then you have a really major update. That makes the situation worse.

Let's be honest, your issue comes from distributions and missing dependencies that don't support D11 yet. This is a real problem, that won't be solved by extending LTS by another year.

You mentioned that several statements in the issue summary are “completely false” and implied that these claims are being made deliberately. If something is incorrect, I’d be happy to adjust the wording. Could you specify exactly what statements are inaccurate and why?

I've already done this for some points, not all of them, because this is eating into time that could be spent doing something more productive. Doing it for every incorrect or misleading point in this issue would take hours, possibly days. And you barely acknowledge the corrections already made, then repeated the false information later - as you've just done here for example:

Drupal does not currently align explicitly with Symfony LTS, but rather follows major versions with no fixed duration.

All Symfony version have a fixed duration, this is clearly documented on https://symfony.com/doc/current/contributing/community/releases.html.

The fact that they extended Symfony 5 support as a one-off commercial agreement at the last minute, does not change their documented release policies which have been the same for several years now.

For Symfony 7:
7.0 released November 2023 https://symfony.com/releases/7.0
7.4 EOL November 2029 https://symfony.com/releases/7.4

As I've already pointed out to you more than once, Drupal major versions are timed to coincide as closely as possible to the *.1 release of a Symfony major version. e.g. Drupal 11 was targeted for June 2024 (actually released in September because we used the 2nd release window) and will be EOL some time in 2028. (when Drupal 12 is released). This was all discussed publicly years ago and is well known at this point. We are not just picking 'random' Symfony releases.

If you actually, constructively, want to increase the lifespan of major Drupal releases, then the first thing to approach would be trying to stretch the window of Drupal major version support to the maximum window of Symfony major version support.

For example Drupal 10 is due to go EOL when Drupal 12 is release, not when Symfony 6 is EOL, this is for multiple reasons:

1. Other dependencies of Drupal 10 may have earlier EOLs than Symfony, so far this isn't a problem but we don't know what will happen in 18 months. You could check all of the dependencies and whether they have any EOLs planned, then clearly document that somewhere.

2. The security team and core committers do not currently have sufficient capacity to maintain three major branches of Drupal at once, e.g. Drupal 10, Drupal 11, and Drupal 12 at the same time. SA-CORE-2025-001 → required releases on five different branches. And extra major version would increase that up to seven. Additional committer funding, and funding for the security team, would help with that.

3. Possibly most importantly, Drupal contrib projects are very unlikely to maintain compatibility with three major Drupal versions at once including for a nearly ten year old version of core. Most of the pain from Drupal major updates is not the major update itself, but because it's the time at which you discover a contrib module you installed four years ago hasn't had a release for two years and has no current active maintainer. This is not actually a problem with the major update, but with that specific contrib module and the fact that contrib maintenance tends to be spread very thinly between a lot of projects. But you find out when you do a major update so associate it with that. Addressing this problem (constructively, not by harassing people in slack) would reduce a lot of the pain associated with major upgrades for sites.

Finally:

D12 (LTS)=S8LTS
D13=S9
D14 (LTS)=S10LTS

With this, it looks like Drupal 12 and 13 would have their EOL on the same date. This means that after a couple of years of Drupal 12, it being 'LTS' does not actually get a new site any longer support than Drupal 13, and Drupal 14 would not be available yet. So I don't see how this would benefit any sites, except those installed early during the Drupal 12 cycle, which is generally not many sites anyway.

The purpose of this issue is to **discuss an LTS strategy for Drupal**, not to debate the formatting or writing style of comments. If there are specific flaws in the proposal, I welcome **concrete feedback** so we can refine and improve it together.

The problem is that the issue etiquette requires you to disclose the use of AI → . In my opinion it offloads the effort from the writer onto the reader as AI-generated content takes a lot more energy to read and understand than if you had written it yourself.

I am having a really hard time understanding what it is you're trying to say precisely because of the formatting. Yet if I look at your comments on other issues, those are crystal clear and easy on the eyes.

However, postponing the issue based on speculation rather than engaging with the core discussion **does not move the conversation forward**.

Not replying to people's questions properly and ignoring issue etiquette doesn't help move the conversation forward either. I've tried to make it clear you're actively hurting your case by presenting it this way but I'll stop commenting on it now as it derails the issue. I will not go as far as postponing the issue again because that would only lead to a ping pong game on the status field.

On topic: I don't see any reason to introduce a new LTS model when we already have a clear major release cycle and LTS for the previous major. Add the fact that upgrading from D10 to D11 is quite painless compared to what major upgrades used to be like and I really don't see the benefit.

-1 from me

I'll be at Drupalcon next month in Atlanta and I'll bring this up directly with Dries in person. If he doesn't care then I'll drop the initiative.

Ibexa got 9 years LTS from Symfony 5.4 . This sets precedent and proves that we can get 5 years of security of Symfony updates for Drupal.

It doesn't prove anything unless you have spoken to Symfony and confirmed that they are willing and able to do this for other versions. Even then you still have the problem that both Symfony and Drupal will require additional funding to do this, for which I have seen no answers in this issue (or elsewhere, for that matter).

If an explicit LTS model isn’t the right path, we should explore extending major version support by 12 months.

An extra 12 months would really help IMHO.

I will reach out to Sensiolabs to get an estimated cost for **an extra 12 months of security updates**. That way, we have real numbers and can see whether this makes financial sense.

If the Sensiolabs ask is too high, we could investigate whether **other vendors would be interested in providing security backports** for an additional 12-month period. There are already proven models for extended security support in other open-source ecosystems.

Given that **drupal.org itself is still running on Drupal 7**, the Drupal Association it'self is already quite familiar with **extended support models** in practice. If Drupal 7 could have extended support for nearly 15 years, we should at least examine whether **12 extra months on major releases** is feasible.

Would core maintainers and the DA be open to reviewing this option once we have concrete cost estimates?

Message sent to Sensiolabs. Waiting for a response

Dear Sensiolabs Team,

I noticed that Ibexa was able to negotiate long-term support for Symfony 5.4, and I was wondering if similar arrangements might be possible for future Symfony versions.

I'm a developer working with an open-source platform that closely follows Symfony majors, but we find the pace of major version transitions quite fast. To explore feasibility, I’d like to understand the estimated cost of extending security support for an additional 12 months beyond the standard EOL for a given Symfony major.

I’ll be attending an open-source conference in March, and having a ballpark cost estimate would be helpful for discussion purposes. We may also evaluate other vendors for security coverage options, so a competitive estimate indexed to inflation (around 2-3% per year) would be ideal.

Would you be able to provide a rough estimate of what such an extended support arrangement might cost?

Looking forward to your insights.

Best regards,
Joseph Olstad

Postponed for a maximum 2 weeks, waiting for a response from Sensiolabs. Meanwhile, if someone has a better suggestion for other vendors, by all means please suggest another vendor that may be willing to and reputable enough to provide the extra 12 months of security updates for Symfony.

Use ES terminology instead of LTS.

Frequent, disruptive upgrades – Organizations and developers spend considerable time updating Drupal’s dependencies rather than improving Drupal itself.

I contest this from two angles.

One, the Smartsheet webteam only does one "upgrade all things" core+contrib session once a year on the two sites it maintains, one of it has more than 260 modules installed, the custom part of the codebase contains 350 .php and .module files in total which contain close to 30 000 lines of custom php code. It rarely takes more than a week. Is this frequent? I don't think so. We established this pattern in the D8 days and since Drupal 10 it is now possible to do it once per two years to upgrade from LTS to LTS. Is that too frequent too?

We do separate out problems or likely problems, "big" contrib changing branches like schema_metatag did in 2024 and rarely core problems. Last year it was ckeditor4 => ckeditor5. If we kept going with ckeditor4 then even more functionality would've been piled on it and the upgrade would've become even more painful.

There was a twig_capture which is highly relevant here: the module hardwired a Twig 1 class name which was deprecated in Twig 2 and dropped in Twig 3 and we didn't catch this until the drop in D10. But, here is the thing: we had the chance if we had ran Rector on this module when D9 went Twig 2. If a Drupal cycle stretched so long we went from Twig 1 to Twig 3 we wouldn't have had even a chance for a peaceful upgrade. This will only repeat in the future.

Without pouring more AI slop in this issue you need to actually substantiate the claim that a) once every two years is too frequent b) by going even further the upgrade doesn't create a massive headache.

Your other claims are AI hallucinations as well: for example, under "Inconsistent support timelines" you list "PHP or Symfony reaching EOL mid-cycle" -- it's possible I missed a Symfony EOL mid-cycle but I can't recall any. Care to give us some examples? PHP EOL is what it is, Zend provides paid PHP LTS versions, expecting the entire open source ecosystem to use it just so Drupal support can be stretched further is not realistic.

But my strongest argument is data which AI slop never is: Symfony is on a four year cycle https://symfony.com/doc/current/contributing/community/releases.html PHP is on a four year cycle https://www.php.net/supported-versions.php and as of Drupal 10 , Drupal is also on a four year cycle.

If you can see a better cycle then instead of posting more AI slop please post dates. Actual dates. How long should Drupal 11 be supported if not four years and how will that work when Symfony and PHP gets out of support because they will . Things like that.

@ghost

Twelve months extra security coverage for even numbered majors.

Drupal 11 is an odd number, no extended security coverage for odd numbered majors under this proposal.

Let me ask again, more short and more precise: as of Drupal 10, you need to upgrade once every two years from Drupal LTS to Drupal LTS. You are planning to spend a significant amount of money to decrease the frequency of two upgrades every four years to two upgrades every five years. (If that is possible of course because there are other dependencies than Symfony , Twig for eg does not have any lifecycle policy I am aware of.)

Is this worth it?

Is this worth it?

I'm hoping that SensioLabs is able to reply with a cost estimate that will provide guidance. How much will that cost the community? Not much if it's spread out, some may get it for free, others may spend a lot or contribute more. It's just like anything else, there's some that give, some that take.

There may be other capable vendors to be discovered other than SensioLabs, we'll see.

I have to say it's much nicer to engage when it's not a wall of generated text, I still haven't seen if you've confirmed or denied utilizing AI or not, it would still be helpful from my perspective to help evaluate the context of the comments.

Back on topic:
I have to ask, isn't this what extended support plans provide from companies like Tag1 and HeroDevs provide?

If there was real demand for this there would be a service for it. Wasn't there extended Drupal 6 security coverage provided by some companies?

Looking back as someone that has supported Drupal for years, the blocker is usually contrib, not core support. Drupal 9 to 10 felt too short, but there were extenuating circumstances there that should not happen again.

From a contrib standpoint 10 -> 11 has been slower, but we have another 14 months or so for Drupal 11. For all of my clients I would say the majority are at the point where there are only 5-10 modules that have not updated. The truth is though if there were longer windows for Drupal 10, people would push even less to update and it would mean contrib's tail would be even longer making upgrade even harder.

@nicxvan,
I've already read your thread on Slack and you're repeating the same accusations over and over again, there's nothing more to add, I already responded on there.

I'll repeat again, I am waiting to hear back from Sensiolabs on the cost of extending Symfony ES. Once we have a number, it’ll be easier to determine if this is viable. If official ES is not an option, then perhaps look at third-party ES models. (maybe there are some available now? Herodevs/Tag1/Others).

I've already read your thread on Slack and you're repeating the same accusations over and over again about AI, there's nothing more to add, I already responded on there.

First of all it was not my thread. Further, I have not accused you of using AI, I have asked several times if you had utilized AI to help respond and you have yet to directly address it. I just read your response in slack and unless you have edited it out you did not address the question of AI there either. A direct answer to that question would help me understand if the comments you made are worth reviewing further or not.

From slack:

I've toned down the ask to a 12 month ES on even numbered Drupals and Symfonys. My comments have also been filtered for tone as I have some emotional baggage attached to this topic.

Back to the salient points.

I know of one public service client that has quite a few still on Drupal 8

Neither of your proposed policies would help them, drupal 8 eol was nov 2021 you would have to extend that by 5 years to still be in coverage.

As for Drupal 11, we released a first build into production sunday afternoon (many more to follow). We're using 4 Drupal 10 modules that were overridden/patched for Drupal 11 compatibility, all the rest were tagged or dev releases. Major lift!

Drupal 10 eol is over a year away, you do not need to upgrade due to security concerns for over a year in the future.

I'm starting to regret even having some sort of idea that this might be well received at some point.

The negative reaction was far, far more due to the rapid fire, giant comments with hard to understand formatting that did not address questions or concerns raised, not your idea in general.

The same folks that put us here (by design, on purpose) do not even want to entertain the idea of extending by twelve months every even numbered major.

That narrower scope is relatively new in the thread and there have been valid concerns raised.

The quote from sensio could be interesting, but I really feel like that is for an organization or group of orgs rather than the community.

I have not seen the clear reason for extended support, the examples you've provided would not have been helped by the policy you are suggesting. So my question here is, who does this extended support help?
What clients?

Even drupal 9 would be out of security support by your policy now since it was eol in 2023, I know you're suggesting even only. But my point is there are 0 Drupal versions that you're policy would affect until 2026, but any drupal 10 sites that cannot update to Drupal 11 by then will need to take on the burden of contrib modules that they need that are no longer maintained anyway.

I updated the issue summary with those details, straight at the top of the issue summary.

This proposal is a one sentence proposal

Twelve months extra security coverage for even numbered majors.

Targetted ES for:

D12 / S8
D14 / S10
D16 / S12
D18 / S14
D20 / S16
D22 / S18
D24 / S20
D26 / S22
D28 / S24
D30 / S26

Even numbers would be ES, all odd numbered releases would be NON-ES

@joseph.olstad did you read #32 before emailing sensiolabs? Drupal 10 EOL ends at least eleven months before Symfony 6.4s EOL so an extra twelve months of Symfony security support would make very little difference there.

@catch, thanks for pointing that out.

So ya, there's potential to offer say, an extra 6 to 11 months of security advisories without even negotiating an ES from Symfony.

I really hate to have to tell you this but @mcdruid and @poker10 did a fantastic job on security advisory releases and bugfix releases for Drupal 7. These two powerhouses could probably maintain an ES stream for 12 months in their sleep.

What are @mcdruid and @poker10 doing now that Drupal 7 is EOL? I would imagine they might be interested in such an initiative.

Perhaps you need to share the load and allow Drupal to grow while you have some margueritas in cabo and celebrate some recent milestone while core security advisory updates happen in your absense.

If we need more muscle to stretch things out 6 to 11 months, let's find some heavy lifters that can handle taking on security advisory coverage?

The same folks that put us here (by design, on purpose) do not even want to entertain the idea of extending by twelve months every even numbered major.

Please quote someone in this issue who did not want to even entertain the idea of extending twelve months. This constant misrepresentation is why you're not getting a positive response here. It reads like a Gish gallop.

I've linked you to previous discussions where this was discussed at length, did you follow the links? These were long, constructive, discussions that eventually led to the current major release cycle (starting with Drupal 10). Here they are again:

#3238372: [policy] Decide on a 2 or 3 year major release cycle →
🌱 [policy] Decide how long major Drupal versions should be supported Needs review
🌱 [policy, no patch] Adopt a regular two year release cadence for major releases Fixed

If you read those discussions, it would have been easy to do so before posting thousands of words in two days on the subject, I would have happily linked to them in slack if you'd asked, then you'd see the various considerations that went into the current policy, which also included whether or not we could extend the EOL further or not. If you have read them, there is no evidence of this happening - you are posting here as if no-one has ever talked about this before. All of these discussions were public, iirc the only private discussions we had about it within the core committer team were checking everyone was OK with what was then a new plan, including people who hadn't been active in the public discussions.

The exact EOL date of Drupal 10 is not actually set yet, partly because we don't know the exact Drupal 12 date and partly because it's the first major release to reach EOL on the new schedule so we did not want to hold ourselves to a date that was either too late or too early.

I'll explain this again, we upgraded early, very early, and I explained in comment number 49 the reasons for this and probably will continue to do so even well into an ES strategy which may or may not get adopted. There's specific reasons why we have to do early builds. I was a bit surprised when @catch mentioned delaying upgrading until after the June release. Coming from straight from the horses mouth!

I've been recommending the following to people for multiple years and know anecdotally that lots and lots of organisations follow the same approach.

If I am working on a new site build and the launch date is somewhere around a Drupal core major release window or shortly afterwards, I will push very hard to try to launch it on the latest major release of Drupal core. This is because any additional work in module compatibility etc. to launch on the latest major version is likely to be offset by not having to update from the previous major version later. In some cases it may also mean not having to apply certain core patches that are already committed to the newer major version but not the old one, being able to start on the latest branches of one or two contrib modules etc, being able to take advantage of new core features sooner, it enforces that custom code doesn't rely on deprecated APIs etc. (which you can also get from phpstan now mostly, but couldn't ten years ago). So there are lots of benefits for a new site to be on the most recent possible version of things.

However, for an existing site, there is no benefit to being an early adopter of a new major version except in very rare cases. Even if 90% of the modules installed on the site have stable Drupal 11-compatible releases on the day 11.0.0 comes out, the other 10% could take weeks or months. So for existing sites, I will look into updating to a new major version at least six months after the initial core
release. for 9.5-10 the window to do this was too short and the reasons for that are both well documented and no longer relevant. For Drupal 10, we are only just entering the period where I would expect people to be updating sites to Drupal 11, so we won't know exactly how it goes for another few months.

If you look at https://www.drupal.org/project/usage/drupal → you can see there are < 30,000 sites on Drupal 11, and about 270,000 sites on Drupal 10.3 and 10.4, and then another approximately 200,000 sites on older Drupal versions that are now unsupported. This is consistent with people starting new sites mostly on Drupal 11, and mostly keeping Drupal 10 sites on Drupal 10 for now. Of the sites that are on unsupported versions, some of them are probably running behind and might jump from 10.1 to 10.4 or something, but also an average of 5,000 sites appear to never update from any minor release, and low ten thousands have ended up stuck on 8.9 and 9.5 - I generally assume these are small sites that are built and then never or rarely updated after that, hopefully that kind of site will start using automatic updates soon, although only the new ones will.

As sites get onto Drupal 10.4, assuming they also keep their contrib modules up to date, then their Drupal 10 site will gradually become more compatible with Drupal 11 as more and more modules release Drupal 11 compatible versions, without them doing anything specific to a Drupal 11 update. Sites can also update their custom code on Drupal 10 to drop deprecated API usages, again this doesn't have to done at the same moment as updating to Drupal 11. Once we get to mid-2025, there will still be hundreds of thousands of sites on Drupal 10, but probably tens of thousands of sites that will be actively trying to update to Drupal 11.1 or 11.2 - at this point the modules that didn't already have a Drupal 11 release from organic maintainer releases or people needing them for new Drupal 11 sites will start to get them (or be confirmed as completely unmaintained).

So when you get towards the end of 2025, if you've kept Drupal 10 core up to date, all your contrib modules up-to-date, and your custom code is clean, then it becomes very clear the remaining work that you will need to do to update to Drupal 11. There will be a rump of modules that are unmaintained without compatible releases, but by waiting a few months you can find out exactly what those modules are with less guesswork. Or like Ghost of Drupal Past does, it's also possible to compress all of this into a much shorter period of time but with the same general window for the Drupal 11 update in the end.

Once you get towards mid-2026, there have then been several minor Drupal 11 releases, new APIs added etc., and you will start to see contrib modules drop support for Drupal 10 (hopefully only in new major versions while Drupal 10 is supported). This is where things gradually start to get harder again, because there is more divergence between the branches, more updates to run between Drupal 10.6 and 11.5 or whatever the versions are by then. Once you're at the end of 2026 and Drupal 12 is definitely out, then contrib modules will start more aggressively dropping support for Drupal 10 so they don't need to maintain support for three major versions at once. Apart from core and security team resources, whether contrib can or will maintain compatibility with three different major versions at once would be the main barrier to doing so, we know there are already thousands of projects that don't maintain compatibility with two.

When 30 different agencies are depending on your base build to work 2 years prior to EOL, that means we have to start working on the next major almost immediately.

This sounds like a distribution or similar platform, and not a specific website. If you are maintaining a distribution, then to be able to launch sites on the new major core version, then yes you would need to work on Drupal 11 compatibility very early. But this does not at all oblige you to update (or recommend updating) existing sites on Drupal 10 until later on. If a distribution depends on contrib modules that are unsupported, then I can see that would be very annoying, and have experienced similar issues myself, but it is not related to the Drupal core release cycle except that it's easier to ignore you're using an unsupported module if you never update anything anyway.

You mentioned funding as an issue, how much did @mcdruid and @poker10 charge for managing D7 over quite a long period? Were they sponsored?

Extending Drupal 7 support did not only require additional work from the Drupal 7 maintainers, it also required additional work from the Drupal 10+ maintainers and other members of the security team, because every security release that affected both versions had to be co-ordinated (down to effectively a few minutes).

This is the huge difference between commercial Drupal 7 extended support (which does not obligate core committers and the security team to co-ordinate releases with the Drupal 7 vendors) vs. the extension of the EOL (twice), which did. You are taking a very glib approach to other people's time and commitments.

There's a whip effect to all this, where a decision or series of decisions made at the core level are a small ripple at the wrist, but by the time the ripple reaches the end of the whip its accelerated. The extra security coverage might seem like the end of the whip for your group however the lack of security coverage is the end of the whip for us.

jQuery 4.0.0-beta2 alone took me at least 500 deliberate steps to deal with where I now have taken ownership of additional libraries, projects and extra responsibilities related to this.

There's a lot of reasons why I now am asking your group to stretch. Its not just jQuery 4.0.0-beta2, it's an accumulation of all the flicks of the wrist coming from majors. All of the flicks of the wrist from the entire upstream.

There's also the sense of timing. We have a lot of clients to serve and the timelines do not cleanly line up. There's a ridiculous sense of urgency for every major in order to stretch our timelines and give the options for our clients.

Drupal is upside down compared to other projects. Microsoft for example eats it's own dog food, they run the next version of their own software before anyone else uses it. Acquia and the DA is the very last organization to switch majors. You've even advised me to delay upgrading until June at the earliest.

The timelines are so short that we had to complete our first upgrade by February.

Just keep doing what you're doing, we'll see where this all goes, we're basically rowing in the same boat but with radically different constraints and standards to follow.

Perhaps pre-mature to close this.

Simplifying the policy to a simpler one sentence idea.

Six months extra security coverage for majors.

Adjusted the scope to six months, but instead of for even numbered majors, now for all majors.

The proposal now just appears to be rehashing the discussion in 🌱 [policy] Decide how long major Drupal versions should be supported Needs review . Note that the Drupal 10 EOL date is not yet set in stone:

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.

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.

These statements still stand; we may decide to extend Drupal 10 EOL, but we are not in a situation to make a decision on that yet, let alone the Drupal 12 EOL as per the issue summary here.

@joseph.olstad, One thing I like about this is the passion you have for improving Drupal. What I don't like is the disparaging comments in #58. Those are not aligned with the Drupal value of "treating each other with dignity and respect". Overall, this issue helped me understand your situation and the upgrade challenges you have to manage.

For reference, the value I referred to is in the Drupal Values & Principles → .

@quietone ,
I faced a windstorm so far on this issue not only here but also in Slack. I've learned a lot though and had I to start this discussion tomorrow I would have a lot more knowledge and approach things in a much simpler iterative type of approach.

I'm a fan of pragmatism, a vastly simplified and reduced scale proposal such as the one we're currently at seems like a positive step forward that has the possibility of gaining traction.

@cmlara posted a fairly lengthy response in Slack about this. He said:

"The last change in policy seems like a good start, though time will tell if it succeeds....."

He goes on to say:

"I would like to see better planning, yes, "we will decide as we get closer" is a dislike". He goes on to say "set the dates and live by them, if something isn't ready pul it out to allow the deadline to be hit, do not be depending upon a secondary release window......

He also mentioned about engineers promises.

You hit a point on the head, for engineers promises matter, saying that and then jumping to "oh we could even cut support early" is the exact opposite of what Engineers want to see. We want to do an update and roadmap when they involve the next update so that we can deal with the dozens of other projects. " .....