Richard, I agree with your proposal herein stated, at least as I understand it.
I would propose that with a W.X.Y semantic version scheme, which I think is what you said, the parts mean essentially [disjoint.overlapping.equal], by which I mean: 1. If two successive versions have a disjoint API and file format, meaning separate namespaces as if they were unrelated projects, and they can't read or write each others' files, then the W at least should be different. You do this between SQLite 2 and 3. 2. If two successive versions have an overlapping but not equal API and file format, meaning that a subset of data files but not all of such readable or writeable by one version is readable and writeable by the other, or that a subset of code but not all of such that is correctly working against one version is likewise against the other, then the X at least should be different. This mainly is for releases that add or remove or change features. 3. If two successive versions have an equal API and file format, meaning that all files readable and writeable by one version are likewise by the other, and all code that works correctly with one version's API does so with the other, then the Y at least should be different. This mainly is for releases that just help performance or fix bugs. 4. Optionally a 4th part Z can be used to indicate maturity such as whether it is a pre-production (including RC) release or production, or be used by third party packagers for packaging version etc. Note that my above definition generally is invariant to the arrow of time, so users can either upgrade or downgrade versions using the same rules with the same expectation of compatibility. That is, the concept of forwards-compatibility and backwards-compatibility are effectively treated the same. The only exception regards fixing bugs, as that is a case where something that works with one version wouldn't work with the other, but in that case no one should be purposefully moving to a buggier version. Of course, newer versions should still always have higher numbers in the position incremented than their prior ones, I'm not suggesting otherwise. Note that optionally one can increment a higher-valued position when they otherwise don't need to based on compatibility, such as for reasons of wanting to define a parallel maintenance branch, or such as for marketing reasons. Richard, does that still seem to describe your intentions? -- Darren Duncan On 2015-10-08 6:38 AM, Richard Hipp wrote: > Several users have proposed that SQLite adopt a new version numbering > scheme. The proposed change is currently uploaded on the "draft" > website: > > https://www.sqlite.org/draft/versionnumbers.html > https://www.sqlite.org/draft/releaselog/3_9_0.html > https://www.sqlite.org/draft/ > > If accepted, the new policy will cause the next release to be 3.9.0 > instead of 3.8.12. And the second number in the version will be > increased much more aggressively in future releases. > > Your feedback on the proposed policy change is appreciated. We will > delay the next release until there is a semblance of consensus on the > new policy. >