Confusion about deprecation and deletion and the correspodings tests in managed packages

Question

We have a managed package and we accidentally deprecated one of our classes - which is not that bad since it really was a deprecated class. But now we noticed that the deprecated class cannot be deleted and it cannot be changed (Class name is already in use) or un-deprecated (the only part I do understand!) any longer. Since the corresponding test class cannot be deprecated at all (for whatever reason) we're now stuck in a kinda inconsistent state. Because the main class will always be shown as it's deprecated and cannot be deleted while the test class can never be deprecated but could be deleted so we would end up with a deprecated class without a test class. And what about the code coverage? Does it matter for deprecated/deleted classes? If so - do I need to have an undeleted class for my deprecated class so I have at least a coverage for class that I cannot delete?

This is one of those Salesforce moments where I could really curse out loud about all those inconsistencies and roadblocks in the platform and I really hope that somebody could shed some light on this issue.

Answer 1

A pragmatic approach is to empty out the class - remove all the lines you can - and keep a minimal test class so your code coverage doesn't suffer. Some debris in a managed package is hard to avoid over time given the way the platform works; I suggest accepting that and keeping your code clean everywhere else that you can is the way to go.

I suggest reserving the revert to beta process that sfdcfox mentions (see Rolling back a managed released package? for more detail) for critical mistakes that you can't live with. We had an example a while ago, where a dependency between packages was accidentally introduced that we definitely could not live with. In that case the several days of trouble - including several uninstalls - was worth it.