Closed (fixed)
Project:
Drupal core
Version:
main
Component:
extension system
Priority:
Major
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
9 May 2020 at 17:28 UTC
Updated:
30 Mar 2026 at 08:40 UTC
Jump to comment: Most recent
Problem/Motivation
We don't have a formal way to deprecate modules in core. In #3062281: Deprecate block_place module for removal in Drupal 9, we deprecated the Place Block module by deprecating basically everything inside it, including the .module file itself. The module had already been hidden in a previous minor release. It was a bit tedious and ad-hoc, and took a long time to implement even though we were deprecating a module that had been already hidden for many releases.
This issue is not for defining the conditions under which a module will be deprecated; that's a separate product management discussion. Rather, it's for discussing how to deprecate a module once the decision has been made to do so.
Proposed resolution
Use the lifecycle property in the info.yml of the module to deprecate and eventually remove the module from Drupal core. To deprecate a module change the lifecycle property to lifecycle: deprecated and add lifecycle_link: link to CR, In the next major release change the lifecycle property to lifecycle: obsolete and add lifecycle_link: link to CR. Also add an update to uninstall the module.
There are two possible scenarios:
- The module is being moved to contrib for future major versions
- The module has no replacement because its functionality has been moved into other modules or APIs (Example: #3111645: Uninstall entity_reference module and prevent it being enabled again, remove deprecated code)
What happens as a result will depend on which of these scenarios are the case.
- There should be a requirements warning for both install and runtime.
- If the module is not being moved to contrib, its APIs should be deprecated.
- If a contrib replacement is being created, the Composer façade should somehow be able to resolve the core module versus the contrib module (whether based on version, project sub-namespacing, or some other mechanism) and the messaging should explain the correct actions to take.
- Modules that have the deprecated module as a dependency should also receive a warning.
- Composer projects that declare a dependency on the module should also receive a deprecation warning and recommend the replacement.
- Automated tooling like Upgrade Status should detect and warn the user about the deprecated module.
Remaining tasks
- #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib
- Can rector or Project Update Bot do anything with this, e.g. replace a dependency on a deprecated extension with its replacement or contrib equivalent?
- Done. Update Drupal deprecation policy to include modules and themes.
Completed child issues
- #3124762: Add 'lifecycle' key to .info.yml files
- #3215043: Indicate the non-stable statuses in admin/modules page
- #3250585: Highlight deprecated modules and themes at admin/reports/status page, providing warning and link with explanation
- #3223453: Check for uses of deprecated and obsolete projects based on the lifecycle info file key
- #3257127: Trigger a deprecation message when a deprecated module or theme is enabled
- #3215044: Promote the non-stable statuses in admin/appearance page, optionally even visually
- #3258782: Do not display obsolete modules at admin/modules
- #3265362: Do not display obsolete themes at admin/appearance
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Release notes snippet
TBD
Comments
Comment #2
catchI think this is a duplicate of #3124762: Add 'lifecycle' key to .info.yml files.
Comment #3
xjmThe one bullet might be a duplicate, but there's more than just the feature to solve. Converting to a meta and maybe that's a child isse.
Comment #4
rpsuYup, it is not just about
statuskey (should that be the way), but alsohidden: trueorexperimental: truewould be possible filter?)Comment #5
xjmWe also need to better solve the mechanics of moving the module into contrib, and the upgrade path for it.
We previously had the notion that we could have both the core module and the contrib one together on the same site and the contrib one would take precedence, which works for sites that are not managed with composer. If the site is managed with composer, however, it breaks because of the namespace issue.
Comment #6
rpsuwould it be possible to rename core-modules with some other pattern? Or does it break too many things such as all tests or something like that?
I am thinking another pattern such as
drupal/quickedit=>drupal/core-quickeditetc. so that overlapping names would not overlap by name.This would probably have severe consequences, which would possibly be too big to take this approach.
Comment #8
catchComment #9
xjm#3005229: Provide optional support for using composer.json for dependency metadata is also relevant to making the process cleaner for Composer sites.
Comment #10
xjmPosted: #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib
Comment #11
xjmComment #12
xjmComment #13
xjmUpdating the IS a bit. We agreed that the APIs should only be deprecated if they won't exist with the same namespace in contrib as this caused us problems in D9. Also added some of the Composer-related considerations.
Comment #14
xjmComment #15
dww#3124762: Add 'lifecycle' key to .info.yml files is getting pretty far along for just the status key itself. It's also starting to deal with some of the other points that this summary does. I'd love some feedback on the desired scope for #3124762, and which parts should be split off into other child issues of this plan.
Thanks!
-Derek
Comment #16
gábor hojtsy@dww: I posted this on the committer meeting and @catch posted feedback at #3124762: Add 'lifecycle' key to .info.yml files about scope just now.
Comment #19
xjmUpdating the IS with some of the child issues.
Comment #20
xjmComment #21
catchComment #22
catchLet's leave profiles out of this for now, that's its own massive set of problems.
Comment #23
xjmAdding missing bullets re: tooling for the deprecated and obsolete statuses.
Comment #24
xjmComment #25
catchComment #26
gábor hojtsyUpdating issue summary with missing upgrade status issue that is already done for some time and marking one done.
Comment #27
gábor hojtsy#3250585: Highlight deprecated modules and themes at admin/reports/status page, providing warning and link with explanation also landed.
Comment #28
quietone commentedUpdated the proposed resolution to include the use of the lifecycle property.
Comment #29
quietone commentedWhat needs to happen so that a section on how to deprecate modules can be added to the deprecation policy?
Comment #30
quietone commentedAdd two issues to the remaining tasks because installing an obsolete module from the UI results in a fatal error and installing an obsolete works when it shouldn't.
Moved completed child issues to the complete section so there is one list of completed.
Comment #31
quietone commentedComment #32
quietone commentedAdd task to update the Deprecation policy page.
Comment #33
quietone commentedComment #37
quietone commentedAll the child issues but one have been fixed. Typically, an meta issue can be closed when that happens but there is one remaining question.
Can rector or Project Update Bot do anything with this, e.g. replace a dependency on a deprecated extension with its replacement or contrib equivalent?
Comment #38
liam morland#3442564: When should the lifecycle switch from experimental to stable?
Comment #40
quietone commentedThe question I asked in #37 I also asked in Slack and the answer was that that can be discussed in #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib. That is the last remaining child issue here, so that is covered.
The documentation has been created and has been improved several times already.
I don't see any else that needs to be done in this issue. I've updated credit.
Comment #41
catchYes everything except for the namespacing problem (which still catches me out based on the direction) is covered and standardised now. Closing out.