liveBook · Manning

Semantic versioning

As explained in The Art of Code

Semantic versioning is a version-numbering convention in which major, minor, and patch components communicate compatibility and change significance.

Semantic versioning communicates the significance of releases through MAJOR.MINOR.PATCH numbers. Major versions signal breaking changes, minor versions add backward-compatible capabilities, and patch versions fix bugs. section 9.4.2

Used consistently, the convention helps developers judge upgrade risk while APIs evolve. Breaking changes include removing response fields, requiring previously optional fields, changing validation rules, or modifying endpoint URLs. When possible, add new behavior alongside the existing interface and keep deprecated methods available long enough for migration. section 9.4.2

Reading a release number

A release moving from 1.4.2 to 2.0.0 communicates a breaking change. A move from 1.4.2 to 1.5.0 communicates a backward-compatible addition, while 1.4.3 communicates a bug fix. Deprecation warnings and replacement guidance give users a practical migration path before an older interface is removed. section 9.4.2

How The Art of Code covers it

How deep it goes
Defines major, minor, and patch meanings, then connects them to compatibility and deprecation without detailing a formal specification.
Examples
Uses breaking fields, validation, endpoint changes, deprecated methods, and MAJOR.MINOR.PATCH release categories as examples.
What you can do after
Evaluate upgrade risk and communicate whether a release breaks compatibility, adds functionality, or fixes defects.
How it connects
Connects semantic versioning with backward compatibility, deprecation, API evolution, and public contracts.

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 The Art of Code. The section links point to the parts of the book it draws on.