liveBook · Manning

Semantic versioning

As explained in API Design Patterns

A semantic version string is a dotted three-number representation whose major, minor, and patch components communicate the nature of software changes.

Semantic versioning uses three dot-separated numbers to communicate the nature of API changes and compatibility expectations. section 24.3.3

Use the components to signal change impact:

  • Increment the major version for backward-incompatible changes, such as renaming a field; code may not continue working across major versions. section 24.3.3
  • Increment the minor version for backward-compatible functionality or behavior changes, such as adding a field under the compatibility policy. section 24.3.3

API field changes

Renaming a field can change version 1.0.0 to 2.0.0, while adding a field can change 1.0.0 to 1.1.0 when the compatibility policy treats the addition as backward compatible. section 24.3.3

Figure 24.4 The different version numbers in a semantic version string

Use the version-number diagram to distinguish the roles of the dotted components. section 24.3.3

How API Design Patterns covers it

How deep it goes
Defines three dotted numbers and explains major and minor semantics, while leaving patch behavior unspecified.
Examples
Uses field renaming and field addition to demonstrate incompatible and compatible API changes.
What it assumes
Assumes a defined compatibility policy for classifying API changes as backward compatible or incompatible.
What you can do after
Apply version increments to communicate whether API changes should preserve existing client behavior.
How it connects
Connects API versioning with backward compatibility and compatibility policy.

Also explained in

Compare how 8 books explain semantic versioning →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.