Semantic versioning in general doesn't have any specific format, it just means that within a project the succession of version numbers conveys information by itself. There's no requirement there has to be 3 parts or whatever. I consider SQLite's versioning scheme to both be very appropriate and it is semantic versioning, not just like such.
As a digression, for my own projects I like to use a semantic versioning scheme of 4 parts like [major.branch.incompatible.compatible] that works like this (assume generally each increment of a part means subsequent parts reset to zeros): 1. Incrementing 'major' means what it typically means, a substantial rewrite that is free to be arbitrarily different and incompatible with the prior major. 2. The 'branch' is inspired by Perl's versioning scheme, in that it alternates between even and odd numbers where even means production and odd means development. When one is making changes that are large enough that there should be dev releases first, eg alpha/beta/etc, a development branch is created and those releases are x.odd.y.z until they're considered production ready, then, the development branch becomes a maintenance branch and releases become x.even.y.z etc. So example first production releases are 1.0.0.0 or 1.2.0.0 etc while first dev/alpha/etc releases are 1.1.0.0 and 1.3.0.0 etc. Each branch may be but isn't necessarily incompatible with prior ones. 3. Incrementing 'incompatible' means that some change was made that is known to break at least some use case, whatever the reason for it, and this was done without having a separate branch / dev-prod status flip. This includes security fixes that disallow something previously allowed. 4. Incrementing 'compatible' means that the authors consider the change to not break anything / be fully backwards-compatible, whether due to being a new feature or a bug fix. -- Darren Duncan On 2015-10-07 1:13 PM, Scott Robison wrote: > Really, the SQLite3 versioning isn't that far off from Semantic Versioning. > Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH. > > Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading > through the release history it is fairly clear that a change in MAJOR > usually results from MAJOR new functionality, MINOR is for relatively MINOR > new functionality, and PATCH is apparently never used outside that context. > > While I personally have no complaints with people who use Semantic > Versioning, I don't see SQLite versioning as being horribly incompatible > with it. In fact, if I were making the decision, I'd keep the current > versioning. >
