I think we can all agree that in an ideal world whenever we upgrade the SF API in managed package code we desire stability in subscriber orgs.
Unfortunately this appears far reaching in the world of Salesforce. Assume the following:
- UtilityClass - on API v27.0 (written few years ago)
- ServiceClass - on API v20.0 (written many years ago)
- Uses PKGA
- Use both packages
- All local code is automatically on the latest API (e.g. 37.0)
With this setup certain functions in PKGA may not work in older subscribers (PKGB) or newer ones (clients). This problem is demonstrated in this SFSE post. To fix this we would need to make the API version across all orgs equal. But, all new code written in client orgs will always be on the latest API! This means if I update the API version in both packages to 37.0 the client will be on 38.0 by next quarter.
This gets even more complicated when there is existing code in the client orgs. Because how often do you update the API version of code written 6 months ago in a LIVE org? Probably never. Even if we keep our packages up to date with the most recent API version the clients can now fall behind!
This looks like a vicious cycle with no viable solutions. The goal here is to achieve stability and confidence in our package upgrades. I appreciate any and all ideas.