Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
During the Drupal 9.5.x cycle, we tried to defer as many issues with deprecations as possible to 10.1, this meant quite a lot of issues were delayed from landing.
I don't think we should do that this time, but we also don't want to create too much of a moving target for contrib compatibility.
On the other hand, we don't want loads of 'best effort' deprecations like constructor arguments to sit around for years.
Steps to reproduce
Proposed resolution
If a deprecation is for @internal code like constructors or plugins, continue to deprecate for removal in 11.x
If a deprecation is for base classes, interfaces, or otherwise likely to affect a lot of modules, deprecate for removal in 12.x
Module/Theme deprecations are allowed - it's actually easier to do these at the end of a major release cycle than earlier on, and while they're slightly disruptive for sites when they update, they're generally not disruptive for contrib or custom modules since the API of the deprecated module stays the same.
There will be lots of edge cases, we can link examples from this issue.
Remaining tasks
f
Comments
Comment #2
bbralaProbably an good idea to be carefull in the coming months. The cycle this time is short and making the transition easy will help a lot in maintaining a positive view on the release cycle of Drupal.
A definitive set of rules on this will indeed be hard, i don't think we'd be able to make a full edgecaseless rule about this.
Comment #3
catchAdding a note about module/theme deprecations.
Comment #4
gábor hojtsyHm, are you saying we defered the issues themselves to sit for a year or we added the deprecation with a target of 10.1? I remember scripting around deprecations for future versions in both deprecation_status and upgrade status, so I don't think that would be new? Eg. my chart data collection is based on these CLI commands, where I already filter out Drupal 12 targeted deprecations, but I think there is only one of these in core so far:
Comment #5
catchI think we did a bit of both in the end. Or maybe I was thinking of 8-9 and we'd already fixed this for 9-10, #3225792: Allow deprecation testing to distinguish between major versions when contrib modules run tests is the issue I was thinking about.
Comment #6
wim leersHm … I wonder if #3225792-11: Allow deprecation testing to distinguish between major versions when contrib modules run tests could be the mechanism to use here?
Comment #7
longwaveFixing related issue link.
Comment #8
catchWe've been doing this in practice since 10.3.x was branched and so far nothing tricky has come up, so being bold and marking RTBC.
Most of the tooling distinguishes between 11 vs. 12 removals, and if it doesn't, then it's still easier to defer deprecations to 12.x than the entire change to 10.4/11.1 or to deprecated for 11.x.
Comment #9
bbralaAdded a child issue I'm rector since I don't think this is currently possible. Next major seems assumed.
Comment #10
catchI made the following edit to the 'allowed changes' page - https://www.drupal.org/node/2581501/revisions/view/13351515/13489588
Going to go ahead and mark this one fixed.