This contains an opinion based on experience:
NEVER EVER EVER mark any code in a managed package as @Deprecated without first completely emptying its implementation.
Marking code as @Deprecated and including that in a release makes two things happen:
- The deprecated item is not visible on any new installs (though is visible to subscriber orgs that started with a version before the deprecation)
- The body of the deprecated item can never be changed!!!
If you leave the body in (we fell for this one - when something is deprecated you usually allow it to continue to work for people for a release or two but...) you make it such that any of the classes/methods/object types/fields/etc. that the deprecated code uses cannot be removed or changed. Ever. Because you can't change the deprecated body content. Ever.
This is a completely broken and very dangerous feature. We have code we can't refactor or remove because it is referenced by something we deprecated years ago. Never again.
So, from my perspective:
- Empty the method (make it just throw an exception with the message "Deprecated")
- Update whatever documentation you have to state that it is no longer valid to use it
- Quietly ignore it - it's up to you to decide whether to keep it in version control and on the release org, or just on your release org...
I understand 2GPs will basically allow you to delete whatever you like. However it is worth noting that it is not currently possible to migrate a 1GP managed package to 2GP and that this migration, as and when it arrives, is not likely to allow you to move the entire content of your 1GP to a 2GP and keep the same namespace. At least that's what I got from a call with a Salesforce Technical Evangelist 2 days ago.