13

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:

  1. 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.

  1. 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: 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

  • 1
    Sounds like a bug to me. I've got my own list of bugs related to method deprecations not being honored/acknowledged in subsequent package versions. – zachelrath Sep 25 '12 at 13:46
  • If you feel you answered your own question, please make it an answer. – Saariko Oct 29 '12 at 8:33
  • Spookily we have just hit a similar issue updating a global class in patch org this morning. In this case we are only changing public, none global methods. We are raising a case for this. – Andrew Fawcett Oct 29 '12 at 10:13
6

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.

  • I did raise a case with Salesforce at the beginning -- took me a while to find a reproducible scenario, so progress has been slow. But they have seen the issue now and are investigating. – Jelle van Geuns Oct 30 '12 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.