[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Klaas V]

On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin  wrote:

>
> On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:
>
> > 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.
>
> I approve of this particular release changing the Y value (i.e. being
> 3.9.0) since it allows SQLite to create and change databases to a format
> which can't be opened with previous versions.
>

I don't care a rat's behind what number changes next in the naming convention 
3vvuupp 
where vv = 'version', uu = 'update' ; pp = patch 

As someone else noted what is the criterion to call a revision major/minor 
version and is one of them applicable in the transition 3081101 to
 309 respectively 3081200. 

If the incompatibilities are as great as feared I'd go to for a new vv, if as 
small as hoped, let's feel free and modest call it "just an" update.

My ?0.02

Kind regards |?Cordiali saluti | Vriendelijke groeten | Freundliche Gr?sse,
Klaas `Z4us` V ?- LinkedIn 437429414

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Jan Nijtmans]

2015-10-08 15:38 GMT+02:00 Richard Hipp :
> 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.

Reading the other reactions, there seems to be consensus on
the next release being 3.9.0, not 3.8.12. So I hope the delay
will not be that much. Details on the exact definition of
X/Y/Z is not that important to me, but since you ask

One idea could be to lower the number of 'major' releases
to about twice a year. This means that Linux distributions,
like Ubuntu and Fedora can know in advance which
SQLite release will match their release.
Ubuntu: 
Fedora: 
(everyone seems to think twice a year is optimal, don't know why)

If there is a desire for new features to be released in between,
this could be done by intermediate 9x releases, at will. e.g.:

3.9.0 -  okt 2015
3.9.1 -  nov 2015  (performance improvement/bugfix only)
3.9.90   -  dec 2015  (well-tested, new feature 1 added + bugfixes)
3.9.2 -  jan 2016  (bugfixes only, without feature 1)
3.9.91   -  feb 2016  (well-tested, new feature 2 added + bugfixes)
3.10.0   -  april 2016 (well-tested, contains feature 1 + 2 + more)
3.11.0   -  okt 2016

3.79.0   -  okt 2050

3.99.0   -  okt 2060;-)

Advantage:
1) less 'major' releases gives the signal to managers that apparently
the software is more stable (even though we know that SQLite's
trunk is very stable always).
2) No limitation when/what to release. It can be fully driven by the
desire of SQLite consortium members: Whenever a new feature
is implemented and ready to be released, it can always be done
in an official 3.x.9y release, outside of the half-yearly schedule.
3) No need to adapt the tarball filename.
4) All 3.x.0 and 3.x.9y releases can be done directly from trunk,
as done now. 3.x.[1-9]+ will generally be done from a branch.
Disadvantage:
1) 3.x.9y releases will give the signal to managers being less
stable than 3.x,y releases. We know that's not necessarily
true, but that's the price for advantage 1)

Just my 2c.

Regards,
   Jan Nijtmans

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Darren Duncan]

Jan, I see no merit to your proposal and plenty of downsides.  SQLite's current 
release schedule works quite well, there is no good reason to formally do 
feature releases just twice a year, especially with that terrible terrible 9x 
kludge.  There's also no reason to pander to guesses about what Linux 
distribution managers think about project stability, their knowing version 
numbers in advance has no value, and they can be explicitly told or read SQLite 
announcements to know what is stable or not.  In reality, distro managers will 
cut releases on their own schedule, and use whatever's the newest SQLite at the 
time, and SQLite itself should be released on its own schedule.  Also, while 
some projects like 6-month feature releases, that is far from a concensus.  I 
know a bunch that like annual releases, Postgres and Perl for example, which 
work well. -- Darren Duncan

On 2015-10-09 1:51 AM, Jan Nijtmans wrote:
> 2015-10-08 15:38 GMT+02:00 Richard Hipp :
>> 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.
>
> Reading the other reactions, there seems to be consensus on
> the next release being 3.9.0, not 3.8.12. So I hope the delay
> will not be that much. Details on the exact definition of
> X/Y/Z is not that important to me, but since you ask
>
> One idea could be to lower the number of 'major' releases
> to about twice a year. This means that Linux distributions,
> like Ubuntu and Fedora can know in advance which
> SQLite release will match their release.
>  Ubuntu: 
>  Fedora: 
> (everyone seems to think twice a year is optimal, don't know why)
>
> If there is a desire for new features to be released in between,
> this could be done by intermediate 9x releases, at will. e.g.:
>
>  3.9.0 -  okt 2015
>  3.9.1 -  nov 2015  (performance improvement/bugfix only)
>  3.9.90   -  dec 2015  (well-tested, new feature 1 added + bugfixes)
>  3.9.2 -  jan 2016  (bugfixes only, without feature 1)
>  3.9.91   -  feb 2016  (well-tested, new feature 2 added + bugfixes)
>  3.10.0   -  april 2016 (well-tested, contains feature 1 + 2 + more)
>  3.11.0   -  okt 2016
>  
>  3.79.0   -  okt 2050
>  
>  3.99.0   -  okt 2060;-)
>
> Advantage:
> 1) less 'major' releases gives the signal to managers that apparently
>  the software is more stable (even though we know that SQLite's
>  trunk is very stable always).
> 2) No limitation when/what to release. It can be fully driven by the
>  desire of SQLite consortium members: Whenever a new feature
>  is implemented and ready to be released, it can always be done
>  in an official 3.x.9y release, outside of the half-yearly schedule.
> 3) No need to adapt the tarball filename.
> 4) All 3.x.0 and 3.x.9y releases can be done directly from trunk,
>  as done now. 3.x.[1-9]+ will generally be done from a branch.
> Disadvantage:
> 1) 3.x.9y releases will give the signal to managers being less
>  stable than 3.x,y releases. We know that's not necessarily
>  true, but that's the price for advantage 1)
>
> Just my 2c.
>
> Regards,
> Jan Nijtmans

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

On 10/8/15, Darren Duncan  wrote:
>
> 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.
>

SQLite has the additional restriction that it does not break legacy.
It only adds new features.  Otherwise, this seems to be a reasonable
description of what I am trying to achieve.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Darren Duncan]

On 2015-10-08 6:03 PM, Richard Hipp wrote:
> On 10/8/15, Darren Duncan  wrote:
>>
>> 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.
>
> SQLite has the additional restriction that it does not break legacy.
> It only adds new features.  Otherwise, this seems to be a reasonable
> description of what I am trying to achieve.

Thank you.

In that case, I could generalize and simplify my proposal as follows...

I would propose that with a W.X.Y semantic version scheme, the parts mean 
essentially [breaks-backward.breaks-forward.breaks-nothing], by which I mean:

1.  If a newer version is incapable of doing something correctly that an older 
version is capable of doing correctly, such as supporting a particular API call 
with same behavior or such as reading or writing a particular file format, then 
the newer version should have a greater W than the older one.  This is for when 
a backwards-compatibility break occurs such as because a feature was removed. 
The key point is a user can not simply take any code or file that works with 
the 
prior version and expect it to work without changes with the newer version.

2.  Otherwise, if a newer version is capable of doing something correctly that 
an older version is incapable of doing correctly, such as supporting a 
particular API call with same behavior or such as reading or writing a 
particular file format, then the newer version should have a greater X than the 
older one.  This is for when a forwards-compatibility break occurs such as 
because a feature was added.  The key point is a user can not simply take any 
code or file that works with the newer version and expect it to work without 
changes with the prior version.

3.  Otherwise, there are no known compatibility breaks, and the newer version 
only needs to have a greater Y than the older one.  Users are free to move in 
both directions as long as any fixed (or created) bugs don't affect them.

Note that while a backwards-compatibility break may happen in the same version 
as a forwards-compatibility break, such as a feature or API or file format 
substitution, this doesn't necessarily have to be the case; adding the new and 
removing the old could be done in separate versions.

As an exception to the above definitions, when W is zero, then X is incremented 
for both backward-breaking and forward-breaking changes (while Y keeps its 
meaning); once W is greater than zero, that stops being the case.

As with before, incrementing a number has no implication on the size of the 
change, just on how it is treated.  For example, a large code refactoring that 
just affects performance but is non-breaking can still be a Y change.

As with before, one can optionally increment a number position without being 
required to, such as for marketing reasons or to mark a maintenance branch.

Note that the main break from my prior proposal is that incrementing W no 
longer 
needs to mean independent product or disjoint API etc, though that is allowed; 
if one wants a position to explicitly mean that only, then I would advocate 
having an extra digit, where a new leaving one, V, means disjoint, and the 
others have the meanings I said above.  But given SQLite's goals, W may never 
increase anyway for decades, so we can save on that redundancy.

-- Darren Duncan

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Darren Duncan]

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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Bert Huijben]

> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin
> Sent: donderdag 8 oktober 2015 16:36
> To: General Discussion of SQLite Database  users at mailinglists.sqlite.org>
> Subject: Re: [sqlite] Proposed new version numbering scheme for SQLite -
> Feedback requested
> 
> 
> On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:
> 
> > 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.
> 
> I approve of this particular release changing the Y value (i.e. being
3.9.0) since
> it allows SQLite to create and change databases to a format which can't be
> opened with previous versions.
> 
> "However, the current tarball naming conventions only reserve two digits
for
> the Y and so the naming format for downloads will need to be revised in
> about 2030."
> 
> If we're still actively using SQLite3 for new projects in 2030 (i.e. we
haven't
> moved on to SQLite4 or something else entirely), they'd better award the
> dev team a solid platinum prize of some sort.

+1

Bert Huijben

BTW: Completed the Subversion testsuite on the 3.8.12 version. No problems
found.

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Simon Slavin]

On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:

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

I approve of this particular release changing the Y value (i.e. being 3.9.0) 
since it allows SQLite to create and change databases to a format which can't 
be opened with previous versions.

"However, the current tarball naming conventions only reserve two digits for 
the Y and so the naming format for downloads will need to be revised in about 
2030."

If we're still actively using SQLite3 for new projects in 2030 (i.e. we haven't 
moved on to SQLite4 or something else entirely), they'd better award the dev 
team a solid platinum prize of some sort.

Simon.

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Scott Robison]

On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin  wrote:

>
> On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:
>
> > 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.
>
> I approve of this particular release changing the Y value (i.e. being
> 3.9.0) since it allows SQLite to create and change databases to a format
> which can't be opened with previous versions.
>

+1

I really don't object to a more "Semantic Versioning" release, but I think
those who really want it are fooling themselves into thinking it will
require less mental effort. Still, it doesn't hurt me or help me to stick
with one or change to the other.


> "However, the current tarball naming conventions only reserve two digits
> for the Y and so the naming format for downloads will need to be revised in
> about 2030."
>
> If we're still actively using SQLite3 for new projects in 2030 (i.e. we
> haven't moved on to SQLite4 or something else entirely), they'd better
> award the dev team a solid platinum prize of some sort.
>

If this change is being made at this time, why not just go ahead and make a
tarball naming convention change now too. Symlinks could easily accommodate
the current convention for as long as is needed / desired. Given the fact
that the last two digits of the current tarball naming convention will
forever after be 00:

filename-3XXYYZZ.ext means filename-3YYZZ00.ext

Go ahead and either start using:

filename-3YYYZZZ.ext (note below)

Or alternatively:

filename-3-Y-Z.ext (or some variation thereof)

The 3YYYZZZ format has two potential flaws. One is the relative sort order,
in that field widths are different in length and quantity. Any future
change will have this problem, so I ignore it.

The other is potential collisions with previous releases. They should be
relatively rare. They can be completely avoided with something more like
filename-3YYYZZZb.ext (or any other character in place of b to indicate it
is part of a different sequence; it can be prefixed or suffixed to the
version number string depending on preferences).

-- 
Scott Robison

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

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.
-- 
D. Richard Hipp
drh at sqlite.org