What are all of the reasons why Salesforce customers should upgrade the API version on their Apex classes, triggers, and pages?

I haven’t been able to find any official documentation or community discussion of the compelling reasons to upgrade the API version on Apex classes, triggers, and pages. I know there is the general answers of “it’s just a good idea” and “they might deprecate support for it eventually”, but for some of our clients those answers are good enough to justify the cost of having a developer invest the time to upgrade the API version and regression test all the code to make sure nothing broke after the upgrade. Are there any more specific reasons in the areas of performance, security, or reliablity that I could use as leverage to convince developers and stakeholders that it should be upgraded on a regular basis?


Contrariwise, I will provide an argument for upgrading, although the other answers state that complacency is acceptable.

There are two factors at play when you speak of API versions: features and consistency. Both of these issues introduce two distinct needs, namely stability and flexibility.

First, let’s address consistency.

You should keep all your classes, pages, and triggers at the same API version. This is important to avoid bugs like this one. Note that this bug only occurs when some classes are lower than v28 and others are higher than v28. Each class appears to run in an emulated model that is compiled in a way that different versions are binary compatible, but having different features. Every once in a while, a newer feature can bleed into an older class, resulting in an error. You need consistency for stability. While the language is very good at what it does, it is not perfect, and you would do well to keep all your code within the same version.

Next, let’s address features.

Inevitably, some CEO/CFO/VP/etc will want to implement a feature. You tell them that it’s no big deal, it can be done in a week. Now, at this point, you’re going to be at one of two places.

If you’re in a habit of not upgrading, you’ll write a new class with a new version, and try to tie it in to everything else, and everything will break. Not necessarily in big ways, but big enough to be noticeable. You’ve ignored the first aspect, consistency. So, you start upgrading all your other classes in the second week. By the third week, they’ve all been upgraded, but now your hunting down bugs that are really obscure, and you have no idea why. A month as gone by, and nobody’s happy, but you swear you’re almost there. Conversely, if you’re regularly upgrading, you’ll simply spend the week writing the new feature, and presto, it’ll be ready.

In other words, by not upgrading, you are not saving time. You are kicking the can down the street, and when you need to upgrade, you’ll be between a rock and a hard place.

I’m not advocating that you jump from v18 to v30 overnight. There are so many changes, so many small nuances you have to consider, that it would be a risky move. I tried something similar to that on a project, and we ultimately got set back months by way of troubleshooting, hunting bugs, etc. But, I’m also not saying that you should kick the can too far down the street. You need to address version upgrades in a controlled manner. There’s nothing wrong with going from v18 to v20, then doing other things and going on to v22, for example.

There are a few versions that will be tricky to upgrade to, because they were significant upgrades. When they introduced “SeeAllData” for example, it required most test methods to be completely re-written or at least modified to use the new attribute. Then, they forced the split between test methods and live code. Who knows what other gamebreaking changes will happen in the future? You want to avoid the last-minute upgrade, because it will put you in a position you don’t want to be in.

So, if you don’t have the resources to be bleeding edge (and many organizations don’t), at least avoid being left in the dust, because you will eventually have to invest the time sooner or later, and the longer you wait, the more time you will have to commit to at once.

Source : Link , Question Author : apexsutherland , Answer Author : sfdcfox

Leave a Comment