[Policy] Define explicit Drupal 10 end of life date of 2026 December regardless of Drupal 12 release

gábor hojtsy → credited catch → .

gábor hojtsy → credited longwave → .

I had the same suggestion in 📌 [policy no-patch] Discuss LTS options Active .

With the original discussions that went into https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas... → there were a handful of main considerations:

1. The possibility of a dependency releasing a new major release and dropping support for the one we use in Drupal 10 before our own EOL - e.g. a Twig 4, jQuery 5, or CKEditor 6. This currently seems very unlikely with any of our main dependencies, and the closer we get to December 2026 the less likely it is that it will happen.

2. A dependency releasing a security issue, and not supporting the minor release that the most recent Drupal 10 depends on. This already happens fairly frequently, we've had a couple of recent examples with Twig. CKEditor5 also comes close sometimes. At the moment Drupal 10 is reasonably up-to-date with PHP dependencies, and we have the option of 10.6.x (December 2025) and even 10.7.x (June 2026) releases if we really needed to.

4. A security vulnerability in actual core code, that affects all three major branches. This will obviously be extra work, but security.drupal.org has access to gitlab now, so MRs against multiple core branches (with test runs) are much easier to manage. And it pales in comparison to having to worry about Drupal 7.

3. Contrib modules feeling obligated to support Drupal 10, 11, and 12 simultaneously. There is no real obligation to do so but a lot of contrib authors do try to support all major branches.

Contrib maintainers can have one minor branch that supports 10/11 and one minor branch that supports 11/12 - this avoids a single branch having to support all three major versions at once. This approach is documented in 🌱 Guidelines for semantic versioning and Drupal core support Active

Also with 📌 Defer disruptive 11.3 deprecations for removal until 13.0 Active , and also OOP hooks and annotations -> attributes, a lot of Drupal 11 deprecations won't get removed until Drupal 13, meaning the required changes to support Drupal 12 should be quite minimal. We've also backported some API additions from 11.x into 10.4 and 10.5.

Related: 📌 Drupal Core strategy for 2025-2028 Active

Not many comments on here, so I am going to go ahead and mark RTBC for now.

+1 to set an explicit D10 EOL date, so that it is predictable. I think December is a good idea, regardless of the D12 release date. However, can we make the bold part more specific?

Define early December 2026 as the definite EOL time for Drupal 10.

If the intent is to set explicit date, can we set it to a specific date and not say "early..."? I agree with @damienmckenna, that setting a specific date may be better (whether it will be 2026-12-31 or some other date in December). Otherwise it is still a "moving target" - though less, but still at least until a certain date closer to the release, when a specific date of the D12 release will be published.

Well there are two options if we wanted to set a specific date I think.

Option 1. The first patch release window in December, usually the first Wednesday of the month. This means we'd allow for an out-of-schedule security release in November, but otherwise no security fixes past the usual November security window. If a dependency has a security release that meant a patch update for core, it could still get a final patch release in December. But if we did option 1, then Drupal 10 wouldn't get a security release in the December security window because that would fall after the EOL date.

2. The usual security window in December, usually the third Wednesday of the month. If a core release went out on this day and affected Drupal 10, Drupal 10 would get a release.

Supporting until any other date doesn't really make sense, because unless it's a security or patch release window, there won't be any releases on that day anyway, so you're really supporting it until whatever the previous release window is. Except we can't promise we wouldn't do an out-of-schedule core release at any time.

Of these, #2 is probably the easier one to explain, although a Drupal 10 security release on Wednesday 16th December 2026 sounds pretty painful to me.

In practice, regardless of either date, if there was a highly critical security release of core, with a simple to backport fix for Drupal 10, it's likely we'd do a 'bonus' release beyond the EOL, but that is a very specific situation that we don't want to make promises about.

Made an attempt at text for the release schedule page, in the proposed resolution of the IS.

Let's be explicit if we agree on Dec 16 :) No link to estimates needed. Updated proposed text.

16th sounds good. Know have some clients who may be relieved

I'm +1 on this policy. The original intent was to:

1. Guarantee full overlapping major-to-major support (so that 10.x can be used up until 12.0.0 ships).
2. Allow us the flexibility to extend support even longer (possibly into 2027) if our dependencies allowed it and we determined it to be best for the ecosystem.

Point 1 combined with "June, August, or December" definitely creates uncertainty we do not want, so I think officially making it December is a good choice. The maintenance minor policy already has caveats in place for handling situations where our dependencies cause issues for us, so I think we can just roll with it.

We can still choose to extend support longer as per point 2 if something comes up that makes it needed.

The only downside of this is that if we achieve a June 12.0.0, we are juggling three major branches for one six-month stretch.

Signoffs needed to make this change would be:

1. ✅ RTBC here (achieved!)
2. Release managers, since they are most directly affected in the RASCI. If we have that consensus, then:
3. Full core leadership team through our decision-making process.
4. Maybe explicit signoff from Dries, since this is the first maintenance major branch EOL date and therefore affects the whole ecosystem.

Let's be explicit if we agree on Dec 16 :) No link to estimates needed. Updated proposed text.

Dec. 16 is incorrect. The correct date for the 2026 December window is December 9. We might adjust this based on other factors. So, I think it is better to say "early December" for now until we actually finalize the schedule. So I changed the IS back to this:

Drupal 10 will reach end of life in early December 2026, when Drupal 12 is released. The last security release of Drupal 10 may be released on this day if needed. No new releases of Drupal 10 will be made after this date.

I’m still telling clients EOL is June or they’ll make us wait. So this will be a pleasant surprise for them

Dec. 16 is incorrect. The correct date for the 2026 December window is December 9.

I think the intent was to set this to a core security release window, which is usually the third Wednesday of the month and that is Dec 16th 2026.

Personally, I prefer more setting up a fixed date, because that will remove any uncertainties. The currently proposed text seems a bit confusing for me, at least the part

in early December 2026, when Drupal 12 is released

, as Drupal 12 could be released also in June.

Saving credits and updating IS.

BTW, 📌 [policy no-patch] Discuss LTS options Active is not actually the same as this issue. This issue is about simply setting a predictable EOL date to reduce uncertainty and acknowledge that 12.0.0 might be released in December 2026. If we use the December window for 12.0.0, there will not be any overlapping support: 10.x would still be EOL the day 12.0.0 is released. Therefore, the goal of 📌 [policy no-patch] Discuss LTS options Active is not met. With our change here, that issue would want us to extend an additional 6 months into 2027, which is a much more difficult proposition and requires all the resourcing and funding and maintainer burden questions posed there. So we should keep the issues separate.

We also have to talk to the sec team here; adding that to the IS.

I spoke to the security team in slack and got a handful of +1s and no objections before this issue was posted, and also linked the issue once it was, so we are sorted there.

I don't think this needs addditional sign-off from Dries - it's just adding details to a schedule that was previously already outlined.

#21 works for me; updating IS accordingly.

I did just think about the one drawback to this -- are contrib maintainers going to be concerned about the extra burden of supporting compatibility for those potential extra 4-6 months? I still think the fixed date is a better choice regardless, but we should consider whether we will need to take additional steps to help support contrib maintainers in that window of overlap.

@poker10:

I think the intent was to set this to a core security release window, which is usually the third Wednesday of the month and that is Dec 16th 2026.

We very much on purpose do not release or EOL any major or minor version on the December security window. :) It is the second week of December, not the third, very much on purpose. :)

in early December 2026, when Drupal 12 is released

Fixed this bit with:

after Drupal 12 has been released.

....Which is true whether it's 6 minutes after or 6 months after. :) The details of the fallback windows are beyond the scope of the table.

Either way, we can update it with the exact date once we confirm the release schedule for 2026 which we are working on currently.

I added #22 to the remaining tasks as a potential followup issue.

@xjm on contrib, I think we could try to promote 🌱 Guidelines for semantic versioning and Drupal core support Active to an actual documentation page somewhere.

There is also 📌 Defer disruptive 11.3 deprecations for removal until 13.0 Active which means the list of APIs deprecated in 11.x and removed in 12.x is going to be quite short. And a lot of 11.x API additions were backported or otherwise made backwards compatible with 10.x (like OOP hooks with #[LegacyHook]).

We very much on purpose do not release or EOL any major or minor version on the December security window. :)

What does this mean if we do a security release on December 16th though? If we don't release it for 10.x, then it wasn't really supported a week earlier either.

Having said that, I would much prefer to close this issue with 'in December' and sort the question of a December 16th 2026 release out if and when we actually have to do one.

@xjm wrote

We very much on purpose do not release or EOL any major or minor version on the December security window. :) The official core window is the second week of December, not the third, very much on purpose. :)

https://www.drupal.org/about/core/policies/core-release-cycles/schedule → indeed says

Third Wednesday (UTC) of every month Security release window for Drupal 11.0.x and 10.3.x

If this remains for 2026 then it will be 16 December.

I think we at least need to change "early December" in the current proposed text to "in December", as 16th would not be early in December as far as I see, it is past mind-month.

Also as @catch pointed out, if there is a security fix to be made for Drupal 10 in December 2026, the current guidelines say that would be released on the 16th of December, not on any other day in December.

Having this discussion in Slack and the issue simultaneously apparently.

I skimmed over #11 originally and disagree with it entirely. Quoting what I said to @poker10:

Basically the promise is that even if it's a day before 12.0.0 comes out, if there is an emergency, you get security coverage. But as the sec team, for run-of-the-mill issues, we would plan to stop stuffing things into D10 with the November window.

1. IMO it must be supported at least until the last possible release date of Drupal 12 (which is the second Tuesday of December, not the third on purpose).

2. We have never EOLed a major release on a security window before.

3. Releasing a final security release on the EOL date of a major would be downright cruel IMO.

4. Supporting it one week longer seems silly and arbitrary to me.

5. The third Wednesday of December is also way too close to the holidays. We already treat the December security window as "for emergency use only" and it has to be canceled like 2/7 the time when the UTC month starts on a Thursday or a Friday.

Just noticed that this got marked NWed which, again, I really don't think the exact date is blocking since it's just filling in the details of the 2026 release schedule which is not set yet.

@catch, @poker10, and I agree that:

1. We will use the December minor release window (which is probably December 9, 2026) as the official EOL date that we publish.
    

2. In the June or August scenario, the 12.1 release announcement will include a section at the bottom mentioning that D10 is EOL. In the December scenario, the 12.0 announcement will include a section at the bottom mentioning that D10 is EOL.
    

3. In practice, the last window that the Security Team might use to issue normal SAs for D10 is probably the third Wednesday of November 2026; everything else is for emergencies and highly critical issues and things like those would probably be addressed even into January at Sec Team discretion, but this is information we don't give the public as an expectation.

Again, I think the important item under consensus here is to support it to a fixed date in December regardless of which D12 release scenario we achieve. The exact date in December is internals of the release schedule.

I think without an exact date, people would easily jump to the wrong conclusions.

I don't agree that EOLing with a security fix is cruel, what would be cruel is a known unfixed security vulnerability coming out right before the holidays (a week after Drupal 10 is EOL), which EOLing on the security window would avoid. Looks like we are not avoiding that then?

The exact date in December is internals of the release schedule

Putting on my Systems Engineer hat:

Exact dates for EOL are should not be internal process, they should be set and given to the public for us to design our plans, how the core team makes that date happen is an internal process.

Releasing a final security release on the EOL date of a major would be downright cruel IMO.

As a Security Engineer:
One last final security fix on the EOL is appreciated (as long as it’s bug free, otherwise a courtesy patch after EOL is called for).

As a Systems engineer: My plans are to be off the software before that date, if for some reason I’m not, I would appreciate the one last final fix, though I do have concerns about system breakage.

I won’t say it is super common that Security EOL is also a release day, though I’ve encounter it a number of times in my life. Ideally yes 100% of the known security issues were buttoned up in November, though all software runs the risk of a new discovery after the last window and that is what the final release covers.

Side note: since Drupal runs a scheduled release cycle, D12.0 release notes should likewise be able to include the date that the 12.x branch will loose all security support and how the Core team makes that date happen would be an internal process.

I don't agree that EOLing with a security fix is cruel, what would be cruel is a known unfixed security vulnerability coming out right before the holidays (a week after Drupal 10 is EOL), which EOLing on the security window would avoid. Looks like we are not avoiding that then?

The point is that we wouldn't do this, regardless of what the official EOL date was. If there was something serious and urgent, we would create a Drupal 10 release regardless. If there was something that wasn't serious, we would simply not use the December window. We choose to skip the December most years, and we will almost certainly skip it in 2026 if there's something affecting D10 that might otherwise be released in it. None of this is new policy; it's how we've handled the EOL of every minor and major branch for as long as I've been involved. So trust the Security Team to continue thinking of users' needs in this regard. :)

I'm just asking people to have patience on the exact date for a couple weeks while we go over the calendar and Drupal events and other holidays and such, not saying that it will say "early December" for any length of time.

Putting the words in the title so people stop worrying over "early December". It's an exact date; we just need to check that the DA isn't putting DrupalCons on the one we have in mind first or that Symfony isn't changing their schedule or etc.

I don't know what did I wrote that sounded like I don't trust the security team. I'm advocating for clear information.

If there were something serious and urgent, we would provide a Drupal 10 release for it regardless of what the windows were and what the D10 EOL date was. If there were something that wasn't serious, we would simply not use the December window for it.

So why is it a window earlier than the security window, but "trust the security team"? The way you explain it is exactly an EOL on the security window. There will either be a last release then or not and there will not be a last release later. So that is the EOL is what you are saying.

Why do we expect people to read between the lines and recall years of practice each personally instead of just stating what the plan is?

So why is it a window earlier than the security window, but "trust the security team"? The way you explain it is exactly an EOL on the security window. There will either be a last release then or not and there will not be a last release later. So that is the EOL is what you are saying.

Why do we expect people to read between the lines and recall years of practice each personally instead of just stating what the plan is?

There won't be any need to read between any lines. The official EOL would be December 9, 2026, just like the official EOL for Drupal 7 was January 5, 2025 (but the last window that would have had "normal" advisories for it was in December 2024, just as the the last window that would have "normal" advisories for Drupal 10 would be November 2026). And in both cases, we wouldn't have published something nasty on the following window without providing a backport as a courtesy to users who did not update before EOL. (As a courtesy, as something that we do beyond what we promise, because it's what's safest for the ecosystem.)

But all that is internal details of best practices; it is a level of detail that confuses people and also adds precisely the vagueness we're trying to avoid, vagueness that will dissuade people from updating. People need an official date to plan around, and the simplest thing to do is to give them the same official date they already have for the December release window, so that there are fewer official dates.

edit: crossposted with xjm, haven't read #34 yet.

Just saying that the EOL is on the security window is not really that clear, because if there is a security release with a bug, it will then need a further patch release to fix it (as cmlara points out).

This could be the day after the EOL in which case 10.x might get it, but since we're talking mid-December and we don't know what the bug might be, then it could be the end of December or January. In some cases we might just not do the follow-up release for Drupal 10 at all if the bug is not 'everyone's site has a fatal PHP error' and it just gets rolled into the usual 12.x/11.x patch release cycle. This kind of thing happens frequently enough.

Drupal 10 sites then have two choices if they're affected by the bug, they can roll back to the previous, insecure, release (the December patch release or a November security release etc.), or they can try to backport the bugfix from 11.x if it exists.

However, if the last security window is in November, then any follow-up bugfixes could happen in the December patch release, which would still be scheduled (if optional) when the EOL is on the 12.1.0 release.

So an EOL on 12.1.0 gets you a final security window in November, + follow-up time, an EOL on the December security window gets you a later final security window but zero follow-up time. One is not necessarily better or clearer.

If there was a Drupalgeddon situation I could see us doing a 'bonus' security release in January, but this is just not something we can announce or promise in advance - obviously the best thing is we don't need to do a security release at all around the EOL.

I don't agree that EOLing with a security fix is cruel, what would be cruel is a known unfixed security vulnerability coming out right before the holidays (a week after Drupal 10 is EOL), which EOLing on the security window would avoid

It doesn't avoid that, because there could be a zero day the day after the EOL. Also a highly critical security release that contains a major bug on the day of the EOL also seems pretty cruel. There is still the chance of off-schedule security releases regardless of any dates we set, because we don't know what might come in. As @xjm has pointed out, we more or less treat the December window as an 'off-schedule' window because it's better if stuff gets released in November or January.

I'm struggling to see why this is such a sticking point given that the EOL for every single minor release we've done since about 2018 has been on the exact day that the minor release + 2 has come out and that's always been before the December security window. And when that's coincided with having to do a security release, we've sorted it out. I have never seen any significant complaints about the 1-2 weeks of uncertainty, and don't know why sorting out that detail has to delay closing a policy issue that narrows this down from an entire six months of uncertainty.

I'm struggling to see why this is such a sticking point given that the EOL for every single minor release we've done since about 2018 has been on the exact day that the minor release + 2 has come out and that's always been before the December security window. And when that's coincided with having to do a security release, we've sorted it out. I have never seen any significant complaints about the 1-2 weeks of uncertainty, and don't know why sorting out that detail has to delay closing a policy issue that narrows this down from an entire six months of uncertainty.

Yes, exactly.

I think the main problem here is that #11 didn't take into account having to do a follow-up bugfix release for a previous security release, and once we do, then it's better to make the EOL coincide with a minor/patch release window rather than the exact day of a security window.

Sites that want to stay secure need to update from Drupal 10 before the EOL. If they are updating to a security release on the day of the EOL in the middle of December then that is an emergency they could have avoided by updating in November. Obviously things happen, but it's not something we want anyone to plan for.

I think an EOL date briefly before a security window looks potentially scary to people, especially with that security window towards the end of the year holidays. But this could very well be just a theory. I understand the past year's practice and internal priorities, but I expect that those are not apparent to most other readers.

Once again, this could very well be a theory that does not hold, I have no way to tell at this point. If the release managers think this is not a communication concern we need to deal with, then we don't.

I think an EOL date briefly before a security window looks potentially scary to people, especially with that security window towards the end of the year holidays.

I think it should only be scary in two situations:

1. A site for whatever reason is deliberately planning to stay on Drupal 10 beyond it's EOL then upgrade in January/February, and hoping they can 'get away with' 6-8 weeks without official support. I think a lot of sites actually did do this with 9.5-10 because there was such a short transition period, and we/they were lucky that there wasn't a serious security issue in the first three months post EOL. However with a predictable cycle set 18 months in advance, and a much longer transition period to 11.x overall, no-one should be planning for this and in fact we should very actively discourage it - for one thing it can make things very complicated with contrib compatibility/support.

2. A site has a planned update to 11.x scheduled for October or November and it keeps getting pushed out - unexpected bugs found at the last minute, people off sick etc. so they end up scheduling it in December but then it gets pushed out again to January. I can absolutely sympathise with this, but this is where our general 'try not to schedule a security release in December' rule kicks in.

People in group #2 won't know they're in it until mid-November at the earliest, so the finer details of the EOL schedule won't be the biggest of their problems (but it might be one of their problems if they still haven't updated by mid-December). The best way to avoid being in group #2 is to plan an update in June-September when there is lots of leeway in case it takes longer than expected to deploy to production, instead of in October-December when there isn't. Announcing the EOL for December 2026 means that people should be able to very confidently schedule the major update for June-September (or earlier) in the knowledge they'll have plenty of extra time if it takes a bit longer. Right now you can't really do that, you'd have to schedule it for January-March 2026 to be sure of having three months leeway or hope that it gets extended by this issue (or a delayed 12.0 release if we didn't have this issue).

A bit off-topic but related to this thread - I've also seen people try to update complex sites to 11.0 or 11.1, dealing with 20-30 (or more) modules that don't have 11.x compatibility yet etc., and this also for me is the 'wrong time' to update unless you have a very, very specific 11.x-only feature you want to use. So maybe it would be worth a 'when is the right time to update Drupal core major versions' blog post or documentation page. For me the ideal time to update from 10-11 would be between June 2025-June-2026 - e.g. when a lot of contrib modules have added 11.x compatibility but before they start thinking about dropping 10.x compatibility.

I think an EOL date briefly before a security window looks potentially scary to people, especially with that security window towards the end of the year holidays. But this could very well be just a theory. I understand the past year's practice and internal priorities, but I expect that those are not apparent to most other readers.

Once again, this could very well be a theory that does not hold, I have no way to tell at this point. If the release managers think this is not a communication concern we need to deal with, then we don't.

I think it only became a concern for @gábor hojtsy because the earlier discussion on the thread drew attention to it without the full context of how we've already handled this safely for six years. I'll go ahead and say now that we will explicitly not release any Drupal-10-affecting-vulns in the IS. Does that address your remaining concern?

Clarified that we will mention the Dec. window bit in the PSA and/or release announcement.

Added mentions of the PSAs and release announcements to the IS. To an RM, these go without saying, but trying to make it explicit for those who might not realize those are an expected part of process to us.

We spoke to stakeholders from the DA today about upcoming event dates, and they're going to try to help get confirmation for us that there will not be a 2026 December DrupalCon so that we can try to finalize this schedule.

Re #39, I don't think in terms of those two groups of people, I think people would look at the date and plan their timeline backwards rather than the other way around.

I think if we say EOL on December 9, 2026, then people would understand that they need to be off of it soon after to not risk an unfixed security problem. If EOL is December 16, then they need to be off of Drupal 10 by the third week of January to avoid a disclosed security problem.

There is a lot of explaining in this issue that either way its most likely December 9 means the same as if Drupal 10 would be supported until January 19 (right before the January security window), but the proposed text is this:

Drupal 10 will reach end of life on December 9, 2026, after Drupal 12 has been released. No new releases of Drupal 10 will be made after this date.

Unless I am misreading this, users of Drupal 10 will need to plan for a disclosed security issue potentially on December 16 with this message. (I am putting aside other institutional knowledge I have because most people reading will not have that information). If our plans are different, it would be reasonable to communicate that IMHO. We don't need to have that as a plan, but I'm advocating to communicate what the plan is, rather than have insider info that is different than what the public information is.

I don't have strong feelings of either date, but I think it is important to document the implications in a way where the internal and external understanding is in sync.

The way I communicate end of life with my clients is that that date is the drop dead date to be off of that version of drupal. The release that date is irrelevant because 10 is no longer supported.

I usually work backwards too and say if eol is December then we need to be on Drupal 11 by September.

I think if we say EOL on December 9, 2026, then people would understand that they need to be off of it soon after to not risk an unfixed security problem. If EOL is December 16, then they need to be off of Drupal 10 by the third week of January to avoid a disclosed security problem.

I think this is not quite institutional knowledge, but you would have to be very, very familiar with Drupal security release cycles to know that 'EOL middle of December probably means you can coast until the middle of January'. And it opens you up to the risk of a critical or highly vulnerability being fixed off schedule in the first week of January and catching you off guard. Either in the core version you're on that's now EOL if we don't do a bonus release, or a contrib module that's dropped support for the branch that still supports Drupal 10 so that the fix is only available for 11|12 compatible releases.

Which is why I would always tell clients the same thing as @nicxvan in #46, even if I know in the back of my mind they might be OK for 4 weeks after EOL if nothing horrible happens.