#11.2.0 release priority

Yay, thanks! I published the CR

catch → closed merge request !11446

Given zero actual usages of those exceptions I think it's fine to add just the annotation. Everything else looks good. Ideally phpstan would ignore deprecated usages inside deprecated code but either it doesn't or it's not perfect.

Committed/pushed to 11.x, thanks!

Huzzah, thanks!

Checked usage in contrib and it could be found in DB-mocks of D7 http://codcontrib.hank.vps-private.net/search?text=UpdaterFileTransferEx...

RTBC as both code and CR looks ready

Re:

except probably exceptions need constructor to throw deprecations

From @catch via Slack:

https://drupal.slack.com/archives/C079NQPQUEN/p1741811869453559?thread_t...

catch: I don't think we have anything explicit for deprecating exceptions, but given these aren't used anywhere outside the system we're deprecating I think just @trigger_error() is fine.
dww: But then I have to add __construct() methods. 😅 Can I just do the annotation, instead?
catch: Sorry that's what I meant...

I'd like to set RTBC but probably exception classes needs constructor to throw deprecation...
but they are inherited so both will throw

Added another API change point for:

• Every method in core/modules/update/update.manager.inc

Everything is now done. Pipeline is green. Simplified remaining tasks.

This is now ready for review (both the MR and the CR). Unassigning.

Thanks!
-Derek

Added an item to API changes for:

• Every method in core/modules/update/update.authorize.inc

Updating remaining tasks to cross off what's done. Almost there...

@andypost: Argh, what are you doing? I assigned this to myself and am actively working on it.

Okay, cool, that's working now.

Adding a TODO list under remaining tasks, and crossing out what's already been pushed...

@andypost, see:
https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... →

I’m assigning myself, since I’ve got more of this done locally. Stay tuned.

Maybe deprecation of hooks could be done in module handler? gonna dig it

I think @group legacy will allow the test to pass with deprecations without changing anything else about it. We have to use that on update test for similar reasons.

I asked in #core-development in Slack, but x-posting here:

core/modules/system/tests/src/Functional/System/SystemAuthorizeTest.php is now failing since it's triggering deprecations. Can I completely remove that test as part of this issue, or do I need to convert it to expect deprecations, etc?

Opened a CR for this (to get a valid NID for deprecation messages) and started deprecating everything in the IS. Pushed commits for authorize.php and system_authorized_*(). Opened an MR. Still incomplete, so NW, but wanted to at least get this started and to see if the bot explodes in any unexpected ways. 😅

@andypost: Not sure what you're requesting in #3. That MR is for a set of changes to completely remove all this code. Instead, it'll probably be more simple to start over from scratch here, since there's now a different scope and approach needed for this issue.

But if I'm misunderstanding, please let me know.

Thanks!
-Derek

Thank you! change record could be published I bet

@dww can you move existing MR here https://git.drupalcode.org/project/drupal/-/merge_requests/10461

catch → closed merge request !11375

Committed/pushed to 11.x, thanks!

Nice! Good to see legacy code being removed. I'm impressed by the diff stat: +9 −1291.

download and update modules and themes through the web interface

using update manager UI)

thank you, fixed relnote

Great, thanks!

Dare we mention any of the motivations in either the CR or release note? That composer is the only supported way to safely manage dependencies? And to pave the way for “automatic updates”? Although the wording / branding is going to be confusing with that, since the new thing is now being called “Update Manager” 😂

Also, I’m not sure we should say “drush or manual updates” in the CR. I thought we want to discourage “manual updates”, and I don’t think drush has a solution for this, either.

CR seems good

both removed functions has zero usage in contrib

added both CR and relnote

rebased and pushed 2 more commits to remove remains of _update_manager_access()

The MR looks good to me, we can remove routes, forms and controllers in a minor release so it's successfully not breaking the bc policy despite being a disruptive change if anyone actually still uses this. However, definitely needs a change record and release note.

Wasn't 100% how to review so I applied the MR and just searched for UpdateManagerUpdate and UpdateReady and think all trace is gone.