Automating revision of version settings for apex classes

Question

I am curious to know if there is a way of automating the version settings for Apex classes. Does anyone have any suggestion on this? Thanks.

Answer 1

Once upon a time, there was an sObject called FeedPost that stored a Chatter feed post. The Great Maker of sObjects at salesforce.com deemed this good.

Until API version 21. When the Great Maker of sObjects deemed FeedPost to not include enough functionality as we now wanted new things in the feed and so FeedPost became FeedItem. And all were happy...

...including developers who had Apex classes using FeedPost who were secure in the knowledge that their code would work provided they didn't need this fancy newfangled FeedItem functionality. Inevitably they upgraded their API versions, but they were grateful to the Apex API version that only made them refactor code when their business requirements forced them to do so and that the new release of API version 21 didn't arbitrarily break their code.

For ten major releases, developers were happy and coded blithely away with this wonderful sObject called FeedItem. But 'lo and behold, a new sObject has recently been foretold in the <safeharbor>pre-release notes for Winter 15</safeharbor>. Soon, the Great Maker will beget a new sObject called FeedElement. What will this portend for our Salesforce developers?

In all seriousness, if you arbitrarily update API versions you are giving yourself work arbitrarily. There is no benefit. We try very hard to give a predictable API so that it doesn't break integrations and code, so customers and app providers can refactor when they need as requirements dictate, or when they decide to perform a technical debt cleanup. This is the whole purpose of the API version: to make your code/integrations predictable. To just go and update because an API version seems too old is just giving yourself headaches and work for no reason.

But if a customer really insisted upon this, here is what I would suggest:

1. Run an upgrade script as per the comments above via the Metadata API. See which classes fail to compile outright. Fix them.
2. Rerun the upgrade script now that you've fixed the compile problems. Now run all unit tests, and find what you've broken. Fix that.
3. Run some end user tests to try to get to test cases not covered by your test code. Collect bugs, fix them
4. Realize that you never ever want to do this process again.

The reality is changes to the standard data model are infrequent at best. And I am exaggerating a bit. But there is no real gain from upgrading API version ever, unless you need to take advantage of a new feature on the platform. I can tell you that we still have customers running integrations against every API version out there and running Apex code against every API version that runs Apex.

Take for example the changes to the Chatter ConnectApi Apex classes coming in Winter15. If you want to use those (and there are some really good reasons to like bulk Chatter updates!), then fine, upgrade those classes to the API Version 32.0 when it goes GA. But if you have a class that is performing some lowly Apex Managed Sharing on an Account record...then why bother!?