I have a lot of apex classes and triggers. Some of them are using limits heavily. Every time new version is available, I'm switching classes on which I work to next version (via Eclipse), so I can have benefits of lesser limits. Also, I believe ( :-) ) that new version has bug fixes. Today, I saw new version in my sandbox, so I switched to version 32.0. I always switch to version current version-1 because I believe ( :-) ) that new version may have bugs.

And now here is a question.
How bugs are fixed in SFDC platform? Are they applied despite of version my class is using? Like, if I use the latest version I have latest benefits. But if I use not the latest version, will I have all fixes?


Some things, like improved limits, apply globally across your classes, regardless of which version you're using. For example, the increased SOQL and DML limits that have occurred over time apply to all versions of code, so you get the benefits without upgrading.

Other things, such as JSON encoding and null instanceof behavior, are version-dependent. If you change your version on some code, you're accepting those changes to behavior. I don't know of a single, comprehensive list of breaking changes, although they are far and few between. The point is, make sure you're testing your code after changing versions.

Generally speaking, if the fix wouldn't disrupt normal behavior and applies to the entire transaction (e.g. limits), then it is applied across all versions. Conversely, if the fix could cause code to break unexpectedly, then it is versioned, and you must choose to use the minimum version required for the fix to apply.

Bugs may be hot-fixed when they are major issues that shouldn't be version specific, such as the LastViewedDate SOQL bug that occurred at some point (note: it's kind of a low priority because there's a valid workaround, but other Known Issues may be fixed much faster). Bugs may be fixed at any build, not necessarily a release, while new features are (almost) always deployed in a new release.

As a side note, you should generally just use the latest version instead of the second latest version (unless you're an ISV, in which case you need to pay attention to the version skew that happens each release). Using the latest code helps identify bugs. If you run into a bug, report it, then downgrade your code version to avoid the bug until it's fixed. If nobody ran the latest version of code, it would result in bugs going unnoticed longer.

| improve this answer | |
  • So, you're saying that version influence on 'system' methods, like String.valueOf or String.isblank? And are they available at all. And if in new version of method implementation is a bug, we can safely rollback to previous version (previous implementation) and we'll be fine. Right? – Andrii Muzychuk Mar 2 '15 at 17:13
  • @Chiz Versioning does affect some system methods (e.g. JSON.serialize), although I don't know of any specific behavior changes on String.valueOf or String.isBlank (they have been the same since the inception of the relevant method). If you roll back to a sufficiently old enough version, I believe String.isBlank wouldn't be available (compilation error). But you can always freely switch between, say, version 33.0 and 32.0 as often as you want, so feel free to explore and test. I recommend using the latest version unless you have a compelling reason not to. – sfdcfox Mar 2 '15 at 17:17
  • I used those methods as examples. I didn't want particular explanation on them ;-) – Andrii Muzychuk Mar 2 '15 at 17:20
  • @Chiz Ah. Too literal of me, then. Anyways, I'd recommend always using the latest version, because the documentation always applies to the latest version anyways. – sfdcfox Mar 2 '15 at 17:21

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.