Problem/Motivation

Before D12 we will have to remove deprecated code, similar to what was done on #3295574: [meta] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 11 branch. On that issue I opened a number of tickets grouping components and modules together by number of deprecations to be removed. This go round I'd like to treat this as a good training opportunity for new users.

Steps to reproduce

NA

Proposed resolution

> Reach out to sub-maintainers if there are any tickets they want to do themselves.
> For the lib folder I’ve grouped them alphabetically by the number of deprecations. Trying to group by 10-15.
> For modules I want to try the same strategy but also by modules that make sense together. Example workspaces + workspaces Ui.
> For now avoid modules or plugins that are marked deprecated to be removed, example migration stuff

Florida Camp
There’s a Drupal Camp happening 2/21-2/23 so I’ve opened single module tickets (going against point 3 above) for first time contributors there. These modules have 1-2 deprecations

After the camp if there any that didn’t get picked up I’ll close and combine into a single ticket. Still a very small MR

Remaining tasks

Get sign off from manager
Open up component tickets.

User interface changes

NA

Introduced terminology

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

Comments

smustgrave created an issue. See original summary.

quietone’s picture

quietone commented
Title: [12.x] [meta] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 11 branch » [12.x] [meta] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules from Drupal 12

@smustgrave, thanks for starting this conversation.

The removals will happen on 12.x when it is create.

quietone’s picture

quietone commented

On a first read the plan looks fine, with one addition and one exception. First, before opening tickets we should discuss scope. And the addition is a point raised by andypost in Slack, which was that all deprecations should have a follow up for the removal.

smustgrave’s picture

smustgrave commented

@quietone

For the D11 META I ended up scanning each component/module first and grouping together alphabetically 2-3 at a time. If the number of deprecations was over 20 or 30 I broke up even further.

As far as the second point that all deprecations should have a follow up I don't know if that's true? Module deprecations probably but if we had follow ups per deprecations there would be 100s of tickets right?

xjm’s picture

xjm
she/her
Primary language English
commented

Along the lines of #3, issues should only be created once the scope has been signed off by release managers and when someone is about to actually do the work, and/or when a maintainer or mentor is guiding the work. I.e., we don't create a bunch of empty issues. We create metas, get scoping signoff, and then create child issues one at a time.

I'm not opposed to asking that specific issues be reserved for a subsystem maintainer and/or for novice contributors, although I would do this on a case-by-case basis instead of as a blanket rule, and set a time limit expectation. It's nice to use these as mentoring issues, but we don't want to do so at the expense of the release deadlines, so we also want to make sure they're done well in advance of the beta deadline. Maybe we want to give one month for novices a chance to work on it, or something along those lines? And make sure it's also 6-8 weeks in advance of the first beta deadline for the June window.

We could use the friendly green comment templates similar to the ones used at contribution sprints. For reference, those look like:

The Drupal Contribution Mentoring team is triaging issues for [event] and we are reserving this issue for Mentored Contribution during the event.

After [date], this issue returns to being open to all. Thanks!

The language we'd use would of course be different, but that formatting is friendly. The goal is to set clear expectations and balance the needs of the issue versus the goals of mentoring.

Thanks @smustgrave and @quietone!

smustgrave’s picture

smustgrave commented

I’m fine with a month timeframe. And this is something I’m willing to help those who work on them.

smustgrave’s picture

smustgrave commented

As far as scope I thought what I did for the D11 removals worked? But also open to tweaking that too. Only time it got complex is when we found we did a deprecation wrong or forgot to update some test config

quietone’s picture

quietone commented

Can you summarize here what you did for Drupal 11. I don't recall.

smustgrave’s picture

smustgrave commented

Wasn't pretty but I just ended up counting deprecations in each folder. For most components I made it's own tickets but there were some that had 1-2 deprecations so I grouped them together.

smustgrave’s picture

smustgrave commented
Issue summary: View changes
Status: Active » Postponed

Probably better status, adding to remaining tasks.

mondrake’s picture

mondrake
Location 🇮🇹
commented
Related issues: +#3550268: Remove deprecated paths from the testing framework, +#3525077: Remove deprecated paths from the Database API & friends

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mondrake’s picture

mondrake
Location 🇮🇹
commented
Related issues: +#3570920: [meta] Adjust parameters in interfaces
smustgrave’s picture

smustgrave commented

Created a few stubs grouping components by number of deprecations. But also have pinged sub-maintainers who want to take care of their own modules or features they were heavily involved in.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Postponed » Active

Unpostponing, we can work on any of these issues now.

@smustgrave thanks for opening the stub issues!

andypost’s picture

andypost
he/him
Primary language Russian
commented
Related issues: +#3488826: [meta] Remove deprecated extensions from Drupal 12
danielveza’s picture

danielveza
he/him
Location Brisbane, AU
commented

Added an issue for LB & Layout Discovery #3571382: Remove deprecations from Layout Builder & Layout Discovery

smustgrave’s picture

smustgrave commented

Created a few more stub tickets for the modules.

Edit.

May seem random and a lot of tickets are crossing (to be expected)
In the lib folder I've made it down to file
In the modules folder I started from the bottom and got up taxonomy (with random ones opened by others)

smustgrave’s picture

smustgrave commented
Issue summary: View changes

Cleaned up the summary some. My idea for first time users for the most part has not worked. Some have been a little more complex.

Now I did open single module tickets for Florida camp this weekend. Any that don’t get picked up by a user there I’ll combine into a single ticket

andypost’s picture

andypost
he/him
Primary language Russian
commented

Filed #3574717: Remove deprecated code from migrate module as node module removal keeping migrate plugins

smustgrave’s picture

smustgrave commented
Issue summary: View changes
quietone’s picture

quietone commented
Title: [12.x] [meta] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules from Drupal 12 » [meta] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules from Drupal 12
quietone’s picture

quietone commented
Related issues: -#3550268: Remove deprecated paths from the testing framework, -#3525077: Remove deprecated paths from the Database API & friends, -#3570920: [meta] Adjust parameters in interfaces, -#3488826: [meta] Remove deprecated extensions from Drupal 12

Moving some related and making them children.