Understanding and managing versioning

As your product functionality grows, it is important to manage the impact this has on developers and partners who have already adopted your APIs in earlier releases of your application and not force them to make code changes unless needed. Where possible, maintain backward compatibility such that even after your application has been upgraded in a subscriber org, existing integrations and extensions continue to work without modification (multiple versions of your application code are not stored in a subscriber org).

Consider adopting Push Upgrades (as discussed in Chapter 1, Building and Publishing Your Application) from the second release of your package and going forward to ensure that your customer base is always on the latest versions of your packages. Managing the released versions in your customer base helps manage your support and testing matrix costs. This chapter will talk about principles that help you avoid the usual concerns customers have when they are not in control of updates to your software. Note that, effectively, Salesforce products and platforms are all automatically upgraded as well.

Without backward compatibility you can inhibit upgrades to your application within your customer base, as the time spent by Developer X addressing API issues can delay upgrades and be expensive. Some subscribers might have utilized consulting services to deliver the original work or be dependent on one of your partners for add-on solution using your API.

Versioning falls into two categories: versioning the definition (or contract determined input and output of data) and the functionality (or behavior) each API represents.

Table of Contents for Understanding and managing versioning

Create new playlist

Sign In

Sign Up

Table of Contents for
Understanding and managing versioning