4

I have an org with hundreds of apex classes, all of which have api versions ranging between 30-37. Is there an easy way to bring them all to the latest api version at once without resorting to manual updates?

1
  • Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken. – Keith C Aug 22 '18 at 18:35
7

WARNING


First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.


You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.

First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.


Force.com IDE (Search > File)

Find Version to Replace

Replace Version


Edit: 2020 Edition

You can use VS Code to do the same thing. Click on Edit > Replace in files, and use the Regular Expression option (far right button next to Search), and you can do this with VS Code. You need to perform a SFDX deploy afterwards.

VS Code Search and Replace

You can also do this with sed/awk and other *NIX (Unix, Linux) shell tools, too. Check the online documentation for your preferred tool.

6

Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.

Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.

If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.


René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.

sfdx muenzpraeger:source:api:set -a 41.0

Reading content of package directories
45 files have been set to API version 41.0.

4
  • any specific examples of times you saw "things breaking in strange and unexpected ways"? – krigi Nov 27 '18 at 21:56
  • @krigi I've definitely seen changes to how things are compiled as the API versions increase. It comes stricter in some scenarios and classes start getting compile errors. There was a point where @IsTest(SeeAllData=false) was a valid keyword but didn't actually do anything at the lower API version. Once it went past that API version it started working as expected. – Daniel Ballinger Nov 27 '18 at 22:08
  • thanks @Daniel. yes, I can think of the SeeAllData as well, API 28 to 29 or thereabouts. Lately, though, I don't have specific "break" examples to draw from when moving UP the API ladder. Is there a comprehensive list of known issues when upgrading API versions, maintained by SF or anyone else, for that matter? – krigi Nov 27 '18 at 22:17
  • @krigi I haven't seen such a list. These things, such as breaking changes, tend to appear in the release notes and then get forgotten about. There were several when the new Apex compiler was released. I haven't seen a single source. It could be something worth putting together and then adding to over time. – Daniel Ballinger Nov 27 '18 at 22:25

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.