chapter twenty four

24 Versioning and compatibility

 

This chapter covers…

  • What is versioning?
  • What does "compatibility" mean?
  • How to define "backward compatibility"
  • The trade-offs involved in choosing a versioning strategy
  • An overview of a few popular versioning strategies for web APIs

The software we build is rarely static. Instead, it tends to change and evolve frequently over time as new features are created and new functionality is added. This leads to a problem: how do we make these improvements without seriously inconveniencing users who have come to depend on things looking and acting as they did before? In this chapter, we’ll explore the most common mechanism for addressing this problem: versioning.

24.1       What is versioning?

Not only is software development rarely static, it is also rarely a continuous process. Even with continuous integration and deployment, we often have checkpoints or launches where some new functionality “goes live” and is visible to users. With web APIs we have a similar scenario: we want to deploy new changes, and we often want to do so with checkpoints of sorts.

24.1.1   Serialization versioning versus service versioning

24.2       What is compatibility?

24.3       Defining backward compatibility

24.3.1   Adding functionality

24.3.2   Fixing bugs

24.3.3   Handling mandatory changes

24.3.4   Under-the-hood changes

24.3.5   Changing semantics

24.4       Versioning strategy trade-offs

24.4.1   Granularity versus simplicity

24.4.2   Stability versus new functionality

24.4.3   Happiness versus ubiquity

24.5       Strategies for web API versioning

24.5.1   Perpetual stability

24.5.2   Agile instability

24.5.3   Semantic versioning

24.6       Exercises

24.7       Summary