Version number policy
Postmill follows the Semantic Versioning 2.0.0 ('SemVer')
convention of assigning version numbers to each tagged release. In short, each
release is given a version number in the
MAJOR.MINOR.PATCH format (e.g.
4.2.1), and these numbers increase depending on whether a release is 'major',
'minor', or a 'patch' (a bug fix). The SemVer spec describes these as follows:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
The SemVer spec is reasonably clear, so it won't be repeated here, but we still have to decide on what is 'backwards-compatible' and what an 'API' is for Postmill's purposes. Postmill is an application interacted with by end-users, it is not a library or framework that other programs build upon. We are not writing code for consumption by programs, we are writing code for the consumption by humans.
Thus, we define a backwards-compatible change as something that's merely considered an evolution of the software. A backwards-incompatible change, by contrast, is then significant alteration or removal of the software's core functionality to the point where the two versions must be considered separate pieces of software. A good rule of thumb is: if upgrading incurs significant loss of functionality, it is a major breaking change.