Drupal Core strategy for 2025-2028

I was writing a reply here, but realized that it's more about Drupal CMS than Core, so I created a new issue there instead: 🌱 [policy] Impact on contributed projects and its maintainers Active .

Putting my core subsystem maintainer hat back on, I appreciate the focus and explicit mention of the entity/field API and UI here, which for a long time was living in the shadows a bit (the API especially, the UI has seen quite some focus recently) compared to the official initiatives that were happening on "fancier", more product-y parts of Drupal (core).

I guess one risk is that funding for those fancier parts might move to Drupal CMS instead, as more modules and possibly features get moved to Drupal CMS/contrib. So we'll need to somehow figure out that Drupal CMS doesn't take away too much of the sunlight that Drupal Core needs.

Ssince this is a long term strategy, it is not version specific, so I am changing to the main development branch.

Putting my core subsystem maintainer hat back on, I appreciate the focus and explicit mention of the entity/field API and UI here, which for a long time was living in the shadows a bit (the API especially, the UI has seen quite some focus recently) compared to the official initiatives that were happening on "fancier", more product-y parts of Drupal (core).

Yes for me entity field API could and should be much further on than it currently is, e.g. it took us nearly ten years to do ✨ Implement a generic revision UI Fixed , various core entities re-implement various things provided by the entity API because they haven't been 100% updated to the generic versions, and we still have weird entity-specific things like node submitted template variables and etc. And this has parallels in views like not having generic entity reference filters (although ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Needs work made some progress in that direction recently). What I think the core strategy should do is recognise these things as key core features to be improved and promoted in their own right, and that has not always been the case as you point out.

I guess one risk is that funding for those fancier parts might move to Drupal CMS instead, as more modules and possibly features get moved to Drupal CMS/contrib. So we'll need to somehow figure out that Drupal CMS doesn't take away too much of the sunlight that Drupal Core needs.

So I would hope that Drupal CMS drives improvements to the following things in core fairly directly:

- recipes
- package_manager / project_browser / automatic_updates
- the installer (to support a project browser/recipes based install process to replace install profiles)
- experience builder (because it can't live in contrib if it's going to replace block UI / layout builder etc.)

But e.g. for experience builder to provide a consistent experience for all content entity types, it will need to tackle some entity API improvements (or at least, specific core entity implementation oddities).

That has not really happened yet except for recipes, obviously XB is making progress but it's not in either CMS or core yet so to early to see all the results of that. But it's early days and hopefully the next six months more of this can happen.

Also if we move e.g. search module to contrib, because Drupal CMS using search_api module, that shouldn't result in less attention on core as such, but just focus attention on one search solution (in contrib) instead of two competing ones (between contrib and core).

In addition to what @berdir and @catch said I think there are some theme specific things that would be great to refresh. Specifically how preprocess, theme_suggestions, and such are discovered and exposed.

This will make Experience build easier to implement and swap out engines and systems most likely so it aligns with CMS as well.

I've got a long list of things I've been uncovering due to Hook work for Installer and Updater bits that could likely use attention.

There's also issues to modernize how render arrays, and form api arrays are generated to make them more discoverable.

Not sure if this is what the feedback is looking for, I can move it elsewhere if it's more suited to another issue.

@nicxvan eventually we'll need to discuss specifics, but for now the focus is really on the overall strategy. First do you agree with the goal? it might not look like it but it's a pretty big change to become a CMS builder (and not "just" a site builder). Did we miss anything in the "where will drupal core play" section? any worries about the realignment of Drupal Core with regard to Drupal CMS, with the CMS market, or even with the broader open-source and commercial world. Does the "how will we win" section make use of all the strengths of Drupal in general, are we missing something to achieve the goal? I think it's more this kind of things we're looking for at this point.

The discussion about the specific APIs, render arrays, theme and hooks is to low level at this time. It'll be easier to discuss once we have a frame of reference we agree on to make decisions. If it's burning your fingers to talk about it right away, a new issue would be best.

Yes agreed with @nod_ technical discussions/specific proposals are probably better for 🌱 [meta] Drupal modernization Active and its child issues or new ones.

But that issue came about from one of the discussions that led to this document. Stuff like how do we make core coherent/consistent; how do we get large changes in more efficiently; how do we follow-through on adding new APIs/features so that they eventually replace older ones, instead of ending up with both the old and new one operating in parallel (or even three+ sometimes) because we moved onto other things instead. And also that much of this work benefits other core features, site builders, contrib, Drupal CMS etc. and is not 'code purity' or simply refactoring even if it's potentially a level or three below what people generally interact with.

So if the reaction is 'great, the core strategy says we should work on the kind of things I think we should work on' then that is very positive feedback, but the specifics of exactly what and how won't end up in here, except as examples of the type of thing.

Make Drupal great for sites with a great number of authenticated users.

That is what Drupal Core is missing. In the market there is a shift towards those kind of sites. Site owners want a more personalized experience for their users and they are switching from anonymous users to authenticated users. It would great if we could use Drupal for kind of sites.
To let Drupal be a great solution for complicated sites with a great number of authenticated users we need to do a couple of things:
1. Start using asynchronous PHP in Drupal Core. At least for retrieving data out of the database. 🌱 [meta] Use Fibers for concurrency in core Active & 📌 Add revoltphp/event-loop dependency to core Active
2. Switch to using MongoDB as the database and store all entity instances in their own JSON object in the database. This will lead to a lot less queries on the database, therefore making Drupal faster. The amount of functionality that Drupal requires from the database for supporting entity instances in JSON object is significant. The only database that can do that is MongoDB. ✨ [meta] Add database driver for MongoDB to Core as experimental Active & 📌 Drupal on MongoDB (the full PR) Active
3. Load the Drupal kernel (and other stuff) in memory before the user request comes in. #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole →

The combination of those 3 solutions combined with a more carefully use of how data is stored in the database and how it is retrieved will make Drupal great for sites with a huge number authenticated users.

The MongoDB community edition has more benefits:
- Support for regular search. We would no longer need a SOLR server next to your Drupal site. It is just stored in MongoDB. The 2 storage's do not need to be kept in sync.
- Support for vector search. Vectors are the way to store the results from an Artificial Intelligence (AI) in a database. With MongoDB those vectors can be indexed and searched. No Vector database needed and no need to keep data in sync between the two.
- Supports horizontal scaling. With this Drupal can support massive numbers of concurrent authenticated users.

The company MongoDB has a 1000 developers working on making the database a better product. The MongoDB has improved enormously over the last 10 years. When you last looked at MongoDB was more then sat 5 years or more. You need to take another look.
The databases we are using now (MySQL & MariaDB) have almost no improvements over the last 10 years. They are what we call lecacy products. MySQL is owned by the Oracle company and they want every user to switch over to their Oracle database. They are doing the minimum amount of support and development on MySQL.
To me, as the subsystem maintainer of the Database API and the database driver modules, MySQL and MariaDB are for the long term not the right database for Drupal.

For more info about Drupal on MongoDB: https://techblog.finalist.nl/blog/drupal-mongodb

Added a link that explains a bit more of the framework https://fs.blog/playing-to-win-how-strategy-really-works/

Thanks for the clarification!

I think if we take my feedback and go a bit higher level, something Drupal needs is an easier way to get a theme that feels customized for a client.

Whether that's a theme ecosystem, or an SDC library that you can easily pull in bits and pieces, or something else entirely, I don't know. But on the medium to low end projects theming is a barrier.

Thanks to @dries and the core committers for getting this discussion going and creating the doc. I really like the change of focus.

Here some thoughts based on the PDF

Drupal Core is a platform that empowers both low-code users and experienced developers to create powerful, user-friendly CMS solutions.

Can we say that certain audiences we don't want to go after? Which ones? Users who aren't comfortable with "low-code"? Meaning you will have to be okay with some code and config? It seems implied in this idoc but not said anywhere the Drupal Core is not really for *everyone* if you have no experience with some web development this is probably not for you. Maybe you start with Drupal CMS? I think this is a good thing to narrow down our audience.

Any organization that already has sites built on Drupal core and are maintaining them long term,

So does this mean Drupal core still has to prioritize these sites even if they don't fall under the current area of where we want to "play"? Does this effectively mean we can’t narrow where we play?

Experienced Drupal developers and site builders who are comfortable hand-picking modules and recipes to build out a site, but are not necessarily going to create their own repeatable CMS for this purpose

(emphasis mine)
Can we narrow the focus to "complex" sites, otherwise it seems to negate the narrowing above to "complex or repeatable"? Drupal core probably isn’t for experienced developers unless they are building a complex site, otherwise there are better solutions.

Where will Drupal Core play?

This is a long list. It would great to hear explicitly where we are not going to play or at least what is the most important in this list. Otherwise it feels like the "playing everywhere" problem mentioned in the video.

Establish channels for faster feedback loops between developers, site builders, and end-users

Which end users? The end users of Drupal core? Or the site builders and the end users of the CMS's built on top of Drupal core?

@daffie - yes, we need to support a lot of authenticated users, but a web application may not behave like a social media site in terms of the kind of data you need to load and show. Still, for our uses we are very much pained by the slowness of loading (and even more) saving entity data en mass. So, entity/field API performance one of our biggest pain points. We also use custom SQL queries at points, so it's not trivial to drop mongoDB in.

More personally in response - it feels ever more intimidating to get involved in core issues and it seems like a lot of good ideas linger with years of discussion. As a (listed) subsystem maintainer I don't feel like I have any special authority or reason to stay involved. Perhaps the core strategy will help define some technical directions that will reduce circular discussions on issues and encourage involvement.

Can we say that certain audiences we don't want to go after? Which ones? Users who aren't comfortable with "low-code"?

? It seems implied in this idoc but not said anywhere the Drupal Core is not really for *everyone* if you have no experience with some web development this is probably not for you.

I think this is very strongly implied if not explicit here:

Experienced Drupal developers and site builders who are comfortable hand-picking
modules and recipes to build out a site, but are not necessarily going to create their own
repeatable CMS for this purpose.

e.g. an experienced no-code site-builder might still want to use Drupal core, because they're familiar with Drupal concepts, contrib modules etc. especially once core ships with project_browser. But if you don't have that experience yet, then Drupal CMS.

So does this mean Drupal core still has to prioritize these sites even if they don't fall under the current area of where we want to "play"? Does this effectively mean we can’t narrow where we play?

I added this bit, and it's intended to communicate that Drupal CMS doesn't provide ongoing upgrade paths for sites built with it, and that means the responsibility falls to core and contrib to provide smooth upgrade paths - partly automatic updates when it's in core, partly having robust and well tested upgrade paths when we add them that don't break people's sites, partly the bc/deprecation/release policies etc.

Can we narrow the focus to "complex" sites,

This makes sense to me.

Thanks for all the effort that already went into this strategy and document, and for the ongoing efforts to focus and clarify goals. This is all extremely valuable work.

Perhaps more relevant for Drupal CMS / Starshot, but since it's called out in this strategy document, too, raising this here:

How will "automatic" updates work with contrib, where there's a huge range of quality, rigor, release management practices, funding vs volunteer effort, etc?

Updates for core is one thing. We've got amazing release managers, a ton of process and best practice, and a whole community of contributors and contrib maintainers helping to make sure releases are solid, upgrade paths work, BC is preserved as appropriate, etc. Most of contrib is maintained as a "one person show", often with no funding at all. Some folks intentionally don't follow semantic versioning semantics because they don't want to be bothered with new branches for new features. Tons of contrib modules have little to no automated test coverage. Letting auto_updates (aka the new "Update Manager") apply releases from all of contrib seems like a disaster waiting to happen.

People have been saying for years that "Drupal should be as easy to upgrade as my iOS device", and I keep responding "that ease is only possible since Apple employs an army of developers and others to ensure that all works flawlessly." Drupal core is sort of equivalent, but contrib is most certainly not. If one of the strategic goals for "how we win" is to "lower the cost of ownership" and put an emphasis on "ease of upgrades", what's the strategic plan to deal with the "wild west" of contrib?

Thanks,
-Derek

p.s. Thanks @Berdir for 🌱 [policy] Impact on contributed projects and its maintainers Active . That's related to my concern here, although that issue is about the impact on contrib maintainers if their module is included in Drupal CMS, while my concern is about the impact of contrib maintainers (and their wide variability on release management practice) on end users (both of core/framework + CMS/product).

How will "automatic" updates work with contrib, where there's a huge range of quality, rigor, release management practices, funding vs volunteer effort, etc?

what's the strategic plan to deal with the "wild west" of contrib?

For me there are multiple parts to this. There is not yet a 'strategic plan' but if we decide that's a goal we want to pursue in the core strategy, then it would be something to spin-off from there.

I do think though that there are small trends in this direction already which we can build on:

Unattended updates will indeed be very challenging, but 'automatic' updates as in attended updates with package_manager should make things easier for people who don't like using composer on the command line. And the problems they'll have with dodgy update paths aren't worse than if you update from the cli, possibly better because there's a bit of additional validation that package_manager does. So it will hopefully make things feel easier for some users.

While there are very varying approaches to maintenance in contrib, in the past couple of years I've noticed widespread adoption of the pattern of adding compatibility for a new major core release without dropping support for the old major, and also without also doing a huge new refactor at the same time. This massively simplifies major site upgrades for site owners because they can update all their contrib modules on e.g. 10.4, then update core to 11.1 (leaving contrib mostly the same), then update contrib again from there. I think this is happening organically because module maintainers also maintain sites, and it's easier when people do this, so the benefits of doing it are felt, and because major versions are every two years now everyone has to do it fairly often. And also the more that everyone follows this pattern, the more obvious it is when people don't, and then there is some degree of peer pressure to follow suit.

We're also trying to make it easier to do this by e.g. having the 10.x maintenance releases post-11.0 and a grace period before major releases where we don't deprecate APIs in the minor just beforehand (or at least deprecate them for removal an extra major ahead e.g. in Drupal 12), and with issues like 📌 Implement utility method for invoking backward compatible code Fixed . We also made sure the OOP hooks patch supported bc for core versions that it doesn't exist in via the LegacyHook attribute, which allows modules to adopt it as soon as they like without even dropping support for 9.5 if they don't want to. That's not possible for everything but it feels like a sign of getting better at doing some of these things compared to even a couple of years ago.

On top of this, it is likely that after a year or two of Drupal CMS, we will see consolidation of some contrib modules because the usage of them will be higher simply due to people installing Drupal CMS, and unless people go out of their way to replace them, other similar modules won't get installed on new sites as often.

Drupal CMS evaluated, not one, not two, not three, but four entity cloning modules in 📌 Evaluate cloning modules Active and eventually went with none of them and used ECA instead - which was able to provide similar functionality and was already being used for something else. There probably don't need to be more than two modules for cloning an entity, definitely not five. I think it's unlikely that we'd add one of the cloning modules to core, but ECA... maybe at some point? Not to pick on the cloning modules, there are probably hundreds of examples of module duplication it's just the one that sprang to mind.

Consolidation of modules doesn't necessarily result in better upgrade paths or maintenance, but it could result in those if there are more people testing, working on bugfixes, offering to co-maintain, fund etc.

--

For me one of the biggest issues when updating to a new core minor release + updating contrib modules is when I've got patches applied that no longer apply. This happens more often than a bug in an upgrade path or actual API incompatibility.

I do liberally use composer patches because I'd rather test and help things get committed upstream than work around them some other way, but also sometimes I just apply the patch and forget.

It is great when patches no longer apply because they've been fixed upstream, then I can just remove the line from composer.patches.json, but if the issue is still open, then it's everything from figuring out if the MR is up-to-date with the version you're applying to, to re-rolling/rebasing, to having to rework the approach entirely. Sometimes it's a spur to move things on to try to get the issue fixed, sometimes you do the bare minimum because it's one in a list of ten things that don't apply any more.

If we are able to improve the focus in core, we might be able to get some very, very long running issues where dozens/hundreds of people have patches applied done more often. An example of that is ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Needs work - followed by 🐛 Views handler loading should respect configuration Needs review , followed by ✨ Configurable views filters to allow for different widgets Active which combined would fully fix an issue that had about 350 followers 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate and barely even loads now) and also cover about 80% of what BEF module does. We've also (and @dww was involved in several of these) been able to fix a lot of 10-15 year old bugs via bugsmash, and some of those were ones where people had patches applied for years too.

None of this necessarily gets us to 'I can switch unattended updates on and my site magically gets updated on cron runs' for anything more than core, but it might get us to 'when I need to update my site, I can run composer update && drush updb -y && drush cex -y and it usually works first time instead of me spending two hours digging around issues'.

There's also possibly standards we could enable contrib maintainers to opt into on d.o - there is opt-in security team support already, but there could also be opt-in major version compatibility conventions (needs a better name) etc., and then those can be used in project browser to push certain modules to the fore.

None of this means that module maintainers would be obligated to do anything, but with project browser + Drupal CMS I think we could see more highlighting of modules that are well supported and less promotion of ones that aren't, and sites will notice that when it comes to update time.

In regards to WordPress...

Organizations might choose WordPress because they perceive it as easier to use for content editors, or because they believe they can achieve their goals with less complex development work compared to building a custom solution with Drupal Core.

Bigger than any of these reasons, I think people see WP as requiring much less effort to maintain long-term. Even with the relatively smooth transition that Drupal has with D10 to D11, WP is still much less. WP's approach of "backwards compatibility forever" has not caught up with it yet (and maybe never will).

When it comes to comparisons with WP, we mostly rely on the fact that no serious engineer would choose WP due to its inferior architecture. That can only take us so far.

While we've done so much to make Drupal major upgrades smooth, I think we still need to do more to remain competitive. We already win in terms of superior content editor UX, and superior project governance. We need to beat them on another pillar in order to gain ground.

First off, thanks to the folks who worked on putting this together. There's a lot here that resonates! I'll save my words for areas I think could use additional work - assume I'm giving high-fives for all the other parts 🙌!

In the "How will we win" section:

Include Project Browser with support for Recipes: I think for the target audience of CMS Builders, this could be narrowed to just Recipes. Many (or in our customer base's case, all) of the target audience don't want tools like Project Browser except on development environments. This usually comes from security and design consistency concerns. They also often have unique hosting requirements that would mean they'd need to build something different on top of Package Manager APIs instead. Of course, a team building a CMS could pull in Project Browser from contrib if they wanted to , and it's going to work just fine.

Make it easier for people to build third-party integrations: This is often a top reason customers bring to us as to why they use Drupal. They know they can integrate third-party services in new and unexpected ways because Drupal's APIs are so robust. So I'm not saying this is a bad goal... I think it's just already been met and is well known outside of the core Drupal community.

Streamline the Drupal upgrade process through automated version updates: Like Dave says above, there's a mix of perception and truth about WordPress being easier and cheaper to maintain. However, unlike WordPress and the Drupal CMS target user, CMS builders are sophisticated enough to have at least small engineering teams using tools like GitHub with devops pipelines. We've worked with small teams with 2-3 developers in higher education who still have very robust code review, CI, and automated testing processes. In our consulting with those teams, the issue isn't that updates are automatic - in fact, they have that sorted out through Dependabot or Renovate. The pain is the work keeping up with compatibility changes in Drupal major releases. Yes, it is so much better than it used to be! But to my surprise, even user-visible improvements like upgrading from CKEditor 4 to 5 haven't been considered worth the upgrade time. In fact, given a choice, our customers have almost always chosen to delay feature upgrades and improvements once sites are launched unless security support requires it.

In other words, I think if we want to win this audience, we need to extend our code compatibility timelines, work with upstream to make that possible, and leave automated updates to Drupal CMS.

Speaking of...

Any organization that already has sites built on Drupal core and are maintaining them long term, this will include Drupal CMS sites after they are launched: That's a little surprising! I think including launched Drupal CMS sites kind of undercuts the narrowing of the audience in the first paragraph. I think it would be more focused to change that to "The developers of Drupal CMS". Since most no-code users won't be able to differentiate between core and CMS code, wouldn't their bugs and support requests first go to the Drupal CMS maintainers, who then bring them to core as appropriate? If the audience is Drupal CMS developers, it gives core more focus while also making a clear home for those users in CMS.

Thanks for all the feedback here it is really encouraging.

On project browser it's tricky because we're not currently planning to add another UI for installing recipes, and it (and update manager) are likely to end up absorbing the update status report, maybe the modules page, at least eventually. So we'd end up with either duplicate interfaces or no interface at all in core if we don't bring it in. I agree the vast majority of sites won't want PB (especially the ability to install anything) enabled in production. Could we completely ditch the modules and themes pages in core in favour of a stable PB in contrib, maybe? The other thing PB would enable is installing Drupal CMS, or a different CMS recipe, or 15 individual recipes, from within the UI installer. But theoretically Drupal CMS could allow that too.

Since most no-code users won't be able to differentiate between core and CMS code, wouldn't their bugs and support requests first go to the Drupal CMS maintainers, who then bring them to core as appropriate?

There is no code in Drupal CMS (except installer customisations), it only adds recipes and contrib modules. So it is possible that support and bug reports will be posted against Drupal CMS but apart from a handful of possibilities they'll always be bugs against core or contrib modules. There are already a consistent (but hard to quantify) number of bugs against contrib modules that get reported against core and have to be moved to the respective project. Maybe some of those will be against Drupal CMS now but otherwise I don't see a change here.

The meaningful change will be moving code out of core, either because it can safely be maintained in contrib and included in Drupal CMS, or because the core feature is outdated and something else entirely is used in Drupal CMS instead (ban vs honeypot for example). But in some cases this will also mean moving code into core too, to replace things.

But to my surprise, even user-visible improvements like upgrading from CKEditor 4 to 5 haven't been considered worth the upgrade time

Unless you had zero integration, a ckeditor5 update was manual refactoring of plugins to a completely different API on a very short timeline. We were able to extend the ckeditor4 security support for Drupal by about 6 months longer than cksource would have supported it otherwise. It was still 12-18 months too short (as with the rest of 9.5). Not only this, but Drupal 10 ended up using the last of the three release windows in large part due to the ckeditor5 upgrade, and this despite having regular meetings and support from cksource to try to unblock ckeditor issues that were critical blockers for us. Without ckeditor5 we could have released 3-6 months earlier and had a longer transition from 9.x

With 10 and 11 I am hopeful the 10.x support until 2026 will mean a more relaxed pace for existing sites. New sites (and Drupal CMS) taking on the majority of the porting/compatibility work, making it easier for sites to update in 6-18 months with less to do. We also deferred some Drupal 10 deprecation removals to Drupal 12 and are already deferring some Drupal 11 deprecation removals to Drupal 13. All of these changes are too recent for anything to feel different for sites yet or to really see the effects. If we have 100,000 sites on Drupal 10 the day it goes eol I will be sad.

What this doesn't account for is the next ckeditor5 situation where upstream just has completely different support timelines to us. We're doing OK with shifting from annotations to attributes. We've been lucky with jQuery/jQuery UI release timing and support timelines but nearly weren't. We are about a year or two behind on phpunit versions because they release a major version every year and aggressively remove APIs we rely on. We still have backbone in core. It's a very mixed situation.

Subject: Advancing an LTS Lifecycle Strategy for Drupal and its Ecosystem
As we consider Drupal's core strategy for 2025–2028, I believe we need a concerted effort to establish a long-term support (LTS) lifecycle for Drupal and its ecosystem, including Symfony, Twig, Doctrine, and PHP. The goal is to minimize disruptive upgrades and refocus on delivering value to end-users while maintaining a predictable development and maintenance cycle.

Why an LTS is Critical

PHP currently releases new minor versions annually, often introducing deprecations that create significant churn downstream. This churn directly impacts Drupal, as we are tightly coupled to the lifecycles of PHP and Symfony. Each year, our efforts are diverted from improving Drupal itself to accommodating upstream changes.

By contrast, successful open-source projects like Ubuntu provide a clear LTS strategy: 5 years of mainline support with an additional 5 years of extended support. This model offers stability for both developers and end-users. Similarly, Drupal 7 demonstrated the value of a stable platform with extended support, lasting over 14 years with relatively low maintenance overhead.

An LTS strategy could bring similar benefits to Drupal and its ecosystem. It would allow us to focus on innovation and stability while reducing the burden of rapid upstream changes. Developers and organizations would gain confidence in building on a platform with a predictable lifecycle.

Proposed Path Forward

1. Engage with Key Stakeholders:
I encourage Dries and the leadership team to collaborate with Fabien Potencier (Symfony), the Twig maintainers, and key contributors to PHP. Aligning on an LTS roadmap for PHP and Symfony would form the foundation of an LTS strategy for Drupal.

2. Advocate for PHP and Symfony LTS:
A longer PHP lifecycle—aligned with Symfony's major releases—could greatly reduce churn. Third-party vendors like Red Hat already provide extended security support for PHP, demonstrating that a long-term strategy is feasible. If a unified approach cannot be achieved, we might explore the possibility of an LTS fork for PHP, Symfony, or both.
3. Lock Versions for Stability:
Drupal's LTS releases could lock to specific versions of PHP, Symfony, and Twig for the duration of the release cycle. This would ensure stability, simplify compatibility testing, and allow for focused innovation within Drupal itself.
4. Provide Clear Choices:
Offering both LTS and non-LTS options could cater to different needs. Most developers and organizations, given a clear roadmap, would likely opt for LTS to minimize risk and disruption.
5. Stub Releases for Upgrade Paths:
To address the concerns about upgrade paths, we could include "stub releases" designed specifically to provide smooth transitions between LTS versions. These releases would focus on upgrade compatibility rather than feature development.

Call to Action

Has there been prior discussion with Fabien Potencier or other key stakeholders about a unified LTS strategy for PHP, Symfony, and their downstream ecosystems? If not, I believe this is a critical topic that needs top-level attention.

The alignment of PHP, Symfony, Twig, and Drupal under an LTS umbrella could transform the ecosystem, benefiting developers, maintainers, and end-users alike. It would provide a sustainable path forward, reducing churn and refocusing efforts on the core mission of Drupal—empowering users with a robust, innovative, and reliable CMS.