Problem/Motivation

We have a long-standing policy of tagging core security releases from the previous tag instead of the current branch, to minimise the set of changes involved for sites to update to the security release.

I think this policy dates back to Drupal 7, and as the core release cycle has developed over the past 10 years I'm not sure it is as useful as it used to be.

At the moment, we have multiple supported and development branches:

main - no releases
11.x - no releases
11.4.x - patch and security releases
11.3.x - security only
10.6.x - patch and security releases.

Last month we had some additional overlap with the 11.2 and 10.5 branches, which were security-only for several months.

To release from the previous tag involves staging all of these multiple branches + MRs against the tag in the private security repositories. This adds a lot of overhead to tagging security releases relative to regular core patch releases. It also requires a freeze on all core branches including main for the duration of the window.

Our security-only branches by definition don't get commits other than for security releases, with a couple of exceptions:

1. Updates to core dependencies that have had their own security releases
2. Very occasionally fixes to random or persistent test failures to make the release process more reliable.

In both of those cases, tagging from the previous security tag release causes problems because it will miss the dependency updates. We end up having to incorporate those commits into the security release process, or doing extra 'bonus' patch releases, as we did for 11.2 and 10.6, or leaving dangling commits on the branch in the case of test fixes.

The only branches that can have new commits on them when it's time to release a security release are 11.4.x and 10.6.x anyway.

10.6.x gets very infrequent commits at this point, it's more or less equivalent to 11.3.x - in its last six months of support.

11.4.x does get much more frequent commits but for the past couple of weeks, approximately half of the commits to 11.4.x have been for (larger or smaller) regressions from 11.3.x. Some proportion of sites will update directly from 11.3.x to an 11.4.x security release, and if that does not include fixes for known regressions since the last minor, this can cause the same problem we're trying to solve. You could say they should update to the latest 11.3.x release first but it's impossible to get hundreds of thousands of site owners to follow the same instructions identically.

In this case we've done three out-of-schedule patch releases for 11.4 to incorporate the fixes to those regressions, but we don't always do that, depending on the issue we often wait a couple of weeks for the regular patch window. Additionally, only a tiny fraction of Drupal sites are on 11.4.x, most are on 11.3.x and 10.6.x

There are two cases where releasing from the branch is riskier, and more likely to make it difficult for sites to update promptly to the security release:

Steps to reproduce

Proposed resolution

Between a patch release (usually the first Wednesday of the month) and a security release window (usually the third Wednesday of the month), freeze backports to release branches. The issues can be left at patch (to be ported) or RTBC.

This leaves the branch 'clean' to tag a security release with only those changes. Dependency updates, fixes for critical regressions etc. which we explicitly want to be bundled with a security release could be backported to the branch on a case-by-case basis.

When we reach the release window, we would either either cherry-pick the backports beginning 24-48 hours after the release (to allow time for a paper bag release if something is wrong with the security release), or as soon as we've announced the window will not be used.

In the case of a highly critical zero day when there are already commits on the branch, we would either:

1. Revert all commits since the previous tag, then unrevert them under the release, to allow releasing off the branch.

2. Branch off the tag and release as we do currently.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

catch created an issue. See original summary.

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes
catch’s picture

catch
he/him
Primary language English
commented

Another thing that makes this less useful than it would be - most sites aren't on the most recent patch release anyway because they don't update to and then deploy to production core patch releases between the time they're released and the next security window.

Note that the numbers below include several releases that actually were security releases, if we have a longer period without security releases in between, a much higher percentage of sites fall behind.

From https://new.drupal.org/project/usage/drupal

11.4.0	6357	9119	0	0	0	0
11.4.1	16603	2119	0	0	0	0
11.4.2	2194	0	0	0	0	0

11.3.10	12449	13105	18235	25702	30999	41902
11.3.11	11442	13680	23724	46702	45620	33725
11.3.12	15430	22686	37927	27729	0	0
11.3.13	39099	44814	27407	0	0	0

10.6.9	24548	28444	39234	55660	58916	67845
10.6.10	12342	15355	25424	43172	41694	30715
10.6.11	23995	28505	44360	31554	0	0
10.6.12	57379	46916	30789	0	0	0
longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

I am +1 to everything mentioned here, the reason this was created was that @catch had already had the idea when I brought it up independently. As one of the few people with the capability of tagging security releases, the additional overhead is painful - especially with the increased cadence of releases recently - and given that we almost always fix more things in patch releases than we break, I think this change would save time and effort for everyone.

I agree that there might be times when we want to fall back to the old method of branching from the previous tag - the highly critical 0-day scenario mentioned in the IS for example - but that should not be the default.

It's worth noting that Symfony and Twig (amongst many other projects) already follow this policy of bundling bug fixes into security releases.

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

The issue summary lists the current branches: main, 11.x, 11.4.x, 11.3.x, 10.6.x. A month ago, we would also consider 10.5.x.

The proposed change does not affect main nor 11.x, since there are no releases on those branches.

I agree with the proposed change for the security-only branches: 11.3.x and (until recently) 10.5.x. Most of the time, the change makes no difference for these branches, and the exceptions mentioned in the issue summary are commits that should be included in any release.

That leaves two branches: 11.4.x and 10.6.x. I think we should be cautious about changing the policy for these.

From Comment #3:

Another thing that makes this less useful than it would be - most sites aren't on the most recent patch release anyway ...

I tell people all the time that the best practice is to keep up to date, so that regular patch releases can be tested in the regular manner and security releases can be deployed quickly, with minimal testing. Behind that advice is the promise that security releases are carefully designed to be minimally disruptive, more so than regular patch releases. I would like to maintain that promise for the benefit of the sites that follow the best practice, even if they are in the minority.

Have we already done as much as we can to automate the process? I know the release managers have a collection of scripts they use for preparing releases; perhaps they can be improved for the case of preparing security releases.

catch’s picture

catch
he/him
Primary language English
commented

I tell people all the time that the best practice is to keep up to date, so that regular patch releases can be tested in the regular manner and security releases can be deployed quickly, with minimal testing. Behind that advice is the promise that security releases are carefully designed to be minimally disruptive, more so than regular patch releases. I would like to maintain that promise for the benefit of the sites that follow the best practice, even if they are in the minority.

I think that would still be good advice.

For example here's the diff between 11.3.6 (April 8th) and 11.3.7 (security release, April 15th):


122c8e16d9a5704808e4db74b682086fc1cded97 fix: #3582171 [PHP 8.5] Strengthen views data with entity types w/o data tables
362ee49789f1695d2aac7e54f78affa4f85fd475 Revert "fix: #3582171 [PHP 8.5] Strengthen views data with entity types w/o data tables"
922c876f1c5b804a3ad25601961fe962ba7ec274 fix: #3582514 Add SensitiveParameter attribute to Crypt::hmacBase64()
8c41072221d5903ff6272066edc02103267a40ba fix: #3526541 Cannot set default values on multi-valued formatted Text fields
892b90d03fc21730e9a3d6fb4ecbb797627b8b71 fix: #3582229 Package Manager blows up when it encounters already-unpacked recipes

There were only five commits to 11.3.x in that time.

Or between 11.3.9 and 11.3.10:

81f510bf6cef807dd0b310516c1ca078ceeda4b7 fix: #3588331 PsrResponseSubscriber doesn't support \Psr\Http\Message\StreamInterface
bf45c9e5179bc2c278222d97b7bf213e4b9cbed4 fix: #3301239 Improve the error message thrown in PoStreamReader::readLine() when translations cannot be saved
c4c50b2dcf6461e01f79831d75246ffe205381b0 Revert "fix: #2844620 Automatically split cache debug headers into multiple lines when they exceed 8k"
f0cd52cd6326b16b5538f9b0d56fb0bebe52a484 fix: #2844620 Automatically split cache debug headers into multiple lines when they exceed 8k
ae286df78d62fd0ffff1188d68bc66806a63e42e docs: #3589633 Remove realityloop from MAINTAINERS.txt
1a191d35cb5bf326b385acc282eb6a1f848c6e89 fix: #3559132 FileSystem::deleteRecursive() leaves files/directories when realpath() returns FALSE
a50bc84789bc577df88731ff1dbb738f9ceeb289 fix: follow-up #3463868 Two #config_targets error when used on a text_format form element
712188eb0dae2e7eb69df38ddc4898261e2e88e7 fix: #3463868 Two #config_targets error when used on a text_format form element
749c427cef21d859445609fac246c8f99fb0cede fix: #3586099 SystemAdminThemePreprocess::preprocessSystemModulesDetails() shows @theme instead of the theme name that depends on a module
745ffb73a4915561b233eef01b36496c0e64f4fc task: #3588897 Widen the script/stylesheet bytes assertion ranges in performance tests

got this by running git log --since 2026-05-06 --before 2026-54-20 --pretty=oneline on the 11.3.x branch.

We're already quite conservative about what goes into patch releases, and I think we'd probably want to be even more conservative if we go ahead here. As mentioned above we could also hold backports to patch release between the patch release date and the security window, and backport them afterwards.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

It has been the Drupal community's recommendation to always do security fixes on their own, to not bundle them with other changes, for core and for contrib. If core's policies change are we also going to stop recommending this process to contrib maintainers too? And if not, why not?

While more complicated, IMHO it's cleaner to do security-only fixes.

godotislate’s picture

godotislate
he/him
commented

As mentioned above we could also hold backports to patch release between the patch release date and the security window, and backport them afterwards.

This seems reasonable. We'd need to make sure not to lose track of outstanding backports, but otherwise this seems straightforward to do.

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes

@damienmckenna I think we can still do security-only fixes with this proposal. As noted in #6 for two recent releases, we've had between 5-10 commits in between the patch release and the security release. We can defer backports for a couple of weeks and bring that down to zero. It needs a little bit of monitoring and thought, but we already have that with backports to patch releases or at the moment especially, between majors too where something like 50+% of 11.x backports need a separate MR.

Delaying backports to release branches also has its own benefits in that it gives time for any regressions to surface against the minor branch first. A recent example' was #3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields - a major bugfix, nothing actually wrong with the commit, but it broke contrib modules that were relying on the long-standing buggy behaviour. If we'd known about that before we'd backported it to the release branch, we could have left the commit in the minor branch and skipped the patch-level backport entirely.

In some cases we actively include non-embargoed fixes into security releases (test fixes, dependency updates, potentially fixes for regressions if we think those would be a barrier to updating to the security release) and those could be backported on a case by case basis much easier than now.

@godotislate yeah it would mean keeping track of https://www.drupal.org/project/issues/search/drupal?text=&assigned=&subm... but we already have to do that to an extent. And the worst case if something gets lost in there is that people have to wait for the next minor release. Updated the issue summary to make that the only proposal, that gets us the main benefits to site owners of the current policy, with the minimum of overhead for us.

Currently we have to freeze commits on all branches for 36 hours for a security window, but if we release off the branches I think we could leave the development branches open more or less throughout.