I @deprecated some interfaces and methods in a minor release (v1.1) of my managed package. Now I’m working on a patch to that minor release (v1.1.1), using a freshly created patch org, and am getting some peculiar behavior:
- I edit and save a class with a @deprecated method and get an error:
“Save error: Deprecation is not allowed in a patch organization”
(referring to the deprecated method). But the method in question was already deprecated in v1.1 prior to the creation of the patch org.
- When I look at the package contents in the patch org I get an error
“A patch version cannot contain any new components. The list below indicates which components you must remove before proceeding with the upload.” The items listed are the deprecated interfaces. I could not find an option to delete them – and anyway it shouldn’t be mandatory to do so since these items are not new.
Seems that something is weirdly corrupted – any pointers on how to resolve would be much appreciated.
Update: removing all the @deprecated tags in the patch org allows me to save and upload a beta version of the package. But uploading a managed version (same code) I get: An unexpected error occurred when uploading your package. Please contact Salesforce Support and provide the following error code: 1442969544-12204 (-1826486931). Ultimately I ended up creating a version 1.2 which seems to handle the deprecation OK so far
Decided to turn this into an answer…
Sadly this (patch orgs and editing within) is definitely one of the less robust areas of the platform. For the sake of our sanity and other ISV’s trying to use this feature we raise as many of these as cases as we can at the time it occurs. Assuming we have time to wait of course.
That said when it works, it is a great feature and we need to help Salesforce drive up the quality with as many repos as we can! So recommend you do the same with your v1.1 to org.
We have seen this is issue with Visualforce Components in the past, claiming that we are adding ‘global’ visibility to them or attributes when all we are doing is editing the code within. Infact I recall a question about this only a few days ago here. In that instance we raised a case and Salesforce fixed internally the issue for us and we where then able to make the update. So although they are different component types, the symptom is the same, maybe worth a try, next time you have the issue.
Update: Also worth still retrospectively raising your case with the error message above, this is known as a Gack, and the numbers allow Salesforce to determine atleast the internal stack trace for the issue. If it matches others, despite not having a repo, they may still be able to help you.