Problem/Motivation
Track the steps needed to deprecate extension Stable 9. See Remove a core extension and move it to a contributed project of the deprecation policy.
The removal of extension Stable 9 was approved in #3512287: [policy, no patch] Deprecate Stable9 and move to contrib.
Remaining tasks
Begin finding someone to maintain the contrib version of the extension. smustgrave has offered to do thisAdd the extension to the list of the Upcoming Deprecations.- Move integrations implemented by other modules to the extension.
Create child issues or child meta issues, as needed, to address the following points. Not all points will apply to all extensions.Move non-migration tests to the extension. Being done in the deprecation issueMove Help Topics to the extension.- For a theme, move theme-specific integration to the theme.
Remove the extension from one or more profiles.Remove references to the extension from database dumps.Remove templates from the extension’s markup.
Do a thorough search of core for any remaining references to the extension. If references are found, outside of the extension, then create issues to remove the references.- Create the contrib project with a stable release, before the alpha version of the major release. Follow the process in Create the contrib project with a stable release for creating the sub tree split.
Deprecate the core extension. #3567667: Deprecate Stable9Open an issue, 'Ensure that Stable 9 does not get special core treatment'#3567860: Ensure that Stable 9 does not get special core treatment- Update the Deprecated and obsolete extensions
Issue fork drupal-3560200
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
quietone commentedComment #3
quietone commentedComment #4
quietone commentedThe policy issue has all the sign-offs and is now RTBC
Comment #5
quietone commentedComment #6
quietone commentedComment #7
quietone commentedDid a search to find usages
Comment #9
andypostI bet it blocked on nobody wanna maintain it so it will stay in core
Comment #10
catchIf no-one steps up to maintain it in contrib, then I'd suggest we mark it obsolete in core - it would mean sites updating to 12.x might need to update their themes for some new markup/CSS.
Comment #11
andypostdeprecation is ready for review #3567667: Deprecate Stable9
Comment #12
quietone commentedThe first two can be done on removal. The later two are being done in the deprecation issue. They should have been done separately but making an exception this time for expediency and it is only 2 tests.
Comment #13
quietone commentedComment #14
andypostLooks there's no willing to maintain it in contrib, what's next steps could be for removal as it's deprecated?
Comment #15
smustgrave commentedWith regards to no volunteers I’d be happy to volunteer. I ended up joining classy after removal to do a d11 release. Only mention to show I got experience managing one of these themes
Comment #16
quietone commented@smustgrave, thanks!
Comment #17
smustgrave commentedI can get the contrib started in the morning if no objections
Comment #18
andypostThank you moving it forward
Comment #19
quietone commentedThese will be done in the removal issue
smustgrave has agreed to be a maintainer for the contrib module. That will be create in due course, I understand he is on holiday now.
Comment #20
quietone commentedComment #21
drummI do not recommend making releases for the stable9 project, or any project being moved out of core, until #3579778: Removed modules should be included as a replace in composer.json is resolved.
Comment #22
xjm@drumm We're at a point in the release cycle where we need to complete these steps as soon as possible or we'll be stuck maintaining the technical debt of these legacy modules and themes for an extra two years. If #3579778: Removed modules should be included as a replace in composer.json is all agreed and committable within the next week or so, then I'm fine with waiting for it to land first. If it's going to be much longer than that, however, that essentially makes #3579778: Removed modules should be included as a replace in composer.json an additional Drupal 12 beta1 blocker.
It might help us to understand what the costs of doing it "the old way" are so we can decide whether to deal with it for this one last major, and then pursue #3579778: Removed modules should be included as a replace in composer.json as a blocker for Drupal 13 module and theme removals instead.
Thanks!
Comment #23
smustgrave commentedSub-tree split made on https://www.drupal.org/project/stable9
Comment #24
drummSee the related issues for #3579778: Removed modules should be included as a replace in composer.json for side effects of continuing to do deprecations the same way. Site owners need to do workarounds of both core & the ban contrib module both providing
drupal/ban. For ban, this was worse because other modules depended ondrupal/ban, so additional workarounds were needed.This isn’t a hard blocker, but it would be good to fix these in general, so removals from core go more smoothly for site owners.
Comment #25
smustgrave commentedSo should I not make a release for stable9? It's fully good to be deprecated and removed.
Comment #26
smustgrave commentedJust wanted to follow up if I should make a stable9 release?
Comment #27
smustgrave commentedDid a stable release https://www.drupal.org/project/stable9/releases/1.0.0
Updated https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol... so believe this one is good?
Comment #28
quietone commentedll the tasks here are complete. There is child issue that is not, which is for infrastructure to do. #3567860: Ensure that Stable 9 does not get special core treatment
I have unpostponed that issue and changed the priority to Major.