Versioning Policy

This document describes how version numbering reflects the type of changes in a new Jansson release. See Releasing on how to make a release.

The version numbering is a usual one: X.Y.Z, where X is major, Y is minor and Z is bugfix release number. If Z is zero, it is omitted from the version string. So, for example, 1.1.2 and 1.2 are valid version numbers but 1.2.0 is not.

Each number is (usually) increased by one at a time, and when one of the numbers is increased, the less significant numbers are reset to zero. To show an example, a stretch of Jansson’s version history is 1.0.3 → 1.0.4 → 1.1 → 1.1.1.

When a new release is made, the version number is increased according to the following rules:

• If there are only bugfixes and the API hasn’t changed at all, the bugfix number Z is increased, e.g. 1.0.3 → 1.0.4
• If there are backwards compatible changes (additions to API), the minor number Y is increased, e.g. 1.0.4 → 1.1
• If there are backwards incompatible changes (changed or removed API), the major number X is increased, e.g. 1.2 → 2.0

This versioning scheme also dictates the development of new features and especially changes in API. There should be a considerable amount of new features when the minor version is increased so that it doesn’t grow very fast. And the major version number should only be increased when there is a serious reason to make backwards incompatible changes to the library.

The libtool version-info current:revision:age should reflect the above policy, too. In a bugfix release, revision is incremented by one (or not at all, if the fix didn’t touch the library, but only documentation, for example). In a minor release, both current and age are incremented and revision is set to zero, to reflect a backwards compatible change. In a major release, current is incremented and age and revision are set to zero, to reflect a backwards incompatible change.