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.
>

Reply via email to