Semantic Versioning

Alas, semver.org is off the mark.
Version numbers can mean something,
but it’s typically not backwards compatibility of interfaces.

Version numbers usually indicate the significance of the change,
often in the amount of stuff changed, why it has changed,
or for sales, marketing and licensing reasons.

Compatibility

Backwards and Forwards Compatibility is the ability of software to read or write interfaces, whether APIs signatures or document file formats.

Backwards Compatibility means that new software is able to read and write the interfaces of older software.

Forwards Compatibility means that older software is able to read and write the interfaces of newer software.

Whether the changes in the interface itself are significant for the software is dependent on what it uses, relies on, and implements.

For example, say a new interface adds an optional field. This is often considered a backwards compatible change. However, if the newer software writes the field with a value, and the policy of the older software is that it Must Understand the content it reads, it may break because there’s a field it doesn’t recognise.

Compatibility is a measure of software, that may change over time as further tests reveal that something that was thought to be backwards compatible is proven not to be.

Thus version numbers should not be relied on to indicate compatibility.

Purpose

Instead the version number may indicate the size or purpose of the change.

Major.Minor.Micro.Build pattern.

Build number indicates branch, date-time, and/or instance of build.

Major indicates major theme or bundle of related functionality.
It may also be the time to remove deprecated functions.

Minor is used for changes that build upon the base Major release.
Usually just adds functionality, but may also mark some items as deprecated.

Micro is used for patches. Patches are usually made to correct minor defects such as typos, so are usually not backward compatible.