[quote=“Enhex”]Usually version numbers go like this:
major.minor.patch
When major means big change to the API, usually something that isn’t compatible with previous major versions.
Minor means additions to the API that shouldn’t break anything.
Patch means small bug fixes, optimizations, and other things which don’t change the API.[/quote]
Why you have the impression that this is not already the case? Our library version has major.minor.patch format. See “librevision.h” file. The major.minor is derived from our Git release tag, while the patch is derived from the number of commits since the last tag. The Git release tag is human controlled. The patch number is auto-incremented by Git. This is done so for practical reason. That is, the contributors are not burden to update this file manually and are not confront with decision making to decide whether a commit is small or API breaking on each commit.
Perhaps, you have mistaken it with our soversion which is stored in “.soversion” file. The soversion is only used for versioning the shared library. Our soversion is also auto-incremented, however, only when the build system detects there is a change in the API documentation. Again, since this is not controlled by a human for practical reason, the build system always increase the patch number of the soversion (no matter how big or small the API change is) and only bump the minor version when the patch number has reached 255, and so on for the minor number before bumping the major number. See github.com/urho3d/Urho3D/issues/419 for more detail.
I hope this answers your query.
