You can use the deprecated annotation on methods, classes, etc in a managed package so they can't be referenced in future releases. However, you can't have the deprecated annotation in any org other than a packaging org. We use ant scripts to deploy code from our subversion repository to an integration org, packaging org, and development orgs. If we add this annotation and check it into source control, it will no longer deploy anywhere other than the packaging org.

Am I missing how this is supposed to work in what seems like a typical development environment? Is there a best practice for using deprecation when the same code gets deployed to multiple orgs?

2 Answers 2


I haven't done any development with managed packages yet. I've only worked on code that would be used within the same company, so I haven't had any use for managed packages. The first time that I saw the need to deprecate something I naturally looked for and found the @deprecated annotation and figured that I could use it just like Java, but it is only available for managed packages. As far as I can tell Salesforce has no built in support for deprecating methods that works universally.

Anyway, back to your issue. You are building out of svn with ant scripts. Could you modify the ant scripts to add in an additional step that does a post checkout step to change the @deprecated to //@deprecated (i.e., comment out) in the non managed builds?

Of course, all of these could be ant targets, etc. that you compose together.

  1. Checkout from svn into temp directory
  2. If it is a non managed package build then execute script/command to search and replace in .cls files, copying files into final directory.
  3. Run ant migration task from final directory.
  • I do a similar thing (manipulate at deployment) in the ant script with the "postInstallScript" node in package.xml which conversely isn't allowed in non-pkg orgs. I already check out into a temp dir, do some manipulation, and deploy from the temp dir so this wouldn't be too hard to implement. My concern is when deploying to a dev org and the files get checked back in they would still have @deprecated commented out. Then I'd need manipulation when deploying to a pkg org to uncomment and hope no one intended to add the comment (since you can't undeprecate, this seems like a safe assumption).
    – Rob Scott
    Commented Aug 15, 2012 at 16:25
  • That makes sense that you'd have to have the logic in place for commenting both ways (in/out) depending on build target. Was in a situation where there were some files that were "corrupted" with no way of taking a permanent fix (long story) and was considering doing a post checkout transformation of the problem files since it was messing up the plans for continuous integration. I think that the temp dir manipulation might end up being the only option for you. Commented Aug 16, 2012 at 22:45
  • Agreed. I wish they would just give a warning and then ignore annotations that don't make sense in the org you are in. It would make it easier in these situations. Instead our deployment script grows more and more complicated.
    – Rob Scott
    Commented Aug 17, 2012 at 17:24

You are correct in your assumption - I have the same issue with our development process, where we use separate dev branch and packaging orgs.

In my case I've simply created my own DeprecatedException, which is a hackish stopgap measure until Salesforce fix the issue (I've just added it to my list of things to raise at Dreamforce).

For the time being, Peters idea is probably the only way to do it - do a regex search and replace to uncomment the deprecation annotations in your packing org.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .