API Versioning in the Enterprise – Minimising the impact of change

There are a number of versioning approaches that we regularly come across in the the IT world including:

  • Semver (http://semver.org)
    • is based on using the versioning information in a build to inform the consumer of the nature of the changes
  • Calver (http://calver.org)
    • calver is based on informing more about release schedules and supportability
  • And even sentimentalver (http://sentimentalversioning.org)
    • probably the default position of many developers but again is based on using versioning to indicate something about what the new version is compared to the previous ones

These strategies have been borne out of software development projects where we control every aspect of the development. They have been extended to work within eco-systems such as node.js to support automated build and dependency management and have worked with some success. In-fact version control based on source code changes has many advantages and should be actively encouraged as:

  • It can be used by automated scripts to attempt to ensure compatibility of software when releasing software,
  • It helps in support when you need to know when a bug was reported and what code was actually live at the time
  • It can help you with bug fix releases
  • You can create version dependency matrices showing what versions of the software are currently deployed and how they relate to each other.

There are often attempts to utilise these strategies for internal services (e.g. SOAP services) and also external API’s. How ever none of the ‘BIG’ api publishers use any of these versioning strategies and even software runtimes such as Java and .NET actually offer you a completely different strategy. Why do we still use these strategies in our enterprise and is there an alternative? Continue reading API Versioning in the Enterprise – Minimising the impact of change