|
|
12
|
|
On 8 Oct 2015, at 2:38pm, Richard Hipp < [hidden email]> 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-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
> -----Original Message-----
> From: [hidden email] [mailto:sqlite-users-
> [hidden email]] On Behalf Of Simon Slavin
> Sent: donderdag 8 oktober 2015 16:36
> To: General Discussion of SQLite Database <sqlite-
> [hidden email]>
> Subject: Re: [sqlite] Proposed new version numbering scheme for SQLite -
> Feedback requested
>
>
> On 8 Oct 2015, at 2:38pm, Richard Hipp < [hidden email]> 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-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
Just my $0.02...
In the proposed new versioning system:
Partial Indexes is clearly something that requires Y to be incremented as Y-1 won't be able to handle a database with partial indexes.
However, CTE is a functionality enhancement that, I believe, does not impact the ability of previous SQLite versions to work with the database. The thing is, I don't believe CTE is simply a "performance enhancement." To me, a "performance enhancement" provides no new functionality, but just works better.
So, I question the exact definition for 'Z'. I think it's pretty much any change that doesn't mandate X or Y changing. Maybe change it to:
"The third number Z is incremented for all other changes, such as performance enhancements and bug fixes."
-----Original Message-----
From: [hidden email] [mailto: [hidden email]] On Behalf Of Jaroslaw Staniek
Sent: Thursday, October 08, 2015 11:33 AM
To: [hidden email]
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested
On 8 October 2015 at 15:38, Richard Hipp < [hidden email]> 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.
>
Thanks, looks solid for me.
PS: For cmake users I am committing myself to update the FindSqlite.cmake detection script in areas where it's needed.
Even for the current versioning approach I introduced SQLITE_MIN_VERSION_PATCH variable among others.[1] Its semantics can be easily made compatible with the proposed new versioning approach by making the variable optional. I welcome any further suggestions, also contributing the file to cmake itself since SQLite is so popular.
[1]
https://phabricator.kde.org/diffusion/KDB/browse/master/cmake/modules/FindSqlite.cmake--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org Calligra Suite:
: A graphic art and office suite - http://calligra.orgKexi:
: A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-usersThis email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
More thoughts...
My quandary is with compatibility in regards to file formats only. If you extend it to API, the CTE would require a Y change. Code that uses SQLite and runs with Y may not operate with Y-1 API.
And, on a side note... the new versioning scheme also means that changes, such as the new Query Analyzer done a few years back (which was a huge boost in performance) would be relegated to a Z change, which makes me sad. ;)
-----Original Message-----
From: [hidden email] [mailto: [hidden email]] On Behalf Of Marc L. Allen
Sent: Thursday, October 08, 2015 11:52 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested
Just my $0.02...
In the proposed new versioning system:
Partial Indexes is clearly something that requires Y to be incremented as Y-1 won't be able to handle a database with partial indexes.
However, CTE is a functionality enhancement that, I believe, does not impact the ability of previous SQLite versions to work with the database. The thing is, I don't believe CTE is simply a "performance enhancement." To me, a "performance enhancement" provides no new functionality, but just works better.
So, I question the exact definition for 'Z'. I think it's pretty much any change that doesn't mandate X or Y changing. Maybe change it to:
"The third number Z is incremented for all other changes, such as performance enhancements and bug fixes."
-----Original Message-----
From: [hidden email] [mailto: [hidden email]] On Behalf Of Jaroslaw Staniek
Sent: Thursday, October 08, 2015 11:33 AM
To: [hidden email]
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested
On 8 October 2015 at 15:38, Richard Hipp < [hidden email]> 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.
>
Thanks, looks solid for me.
PS: For cmake users I am committing myself to update the FindSqlite.cmake detection script in areas where it's needed.
Even for the current versioning approach I introduced SQLITE_MIN_VERSION_PATCH variable among others.[1] Its semantics can be easily made compatible with the proposed new versioning approach by making the variable optional. I welcome any further suggestions, also contributing the file to cmake itself since SQLite is so popular.
[1]
https://phabricator.kde.org/diffusion/KDB/browse/master/cmake/modules/FindSqlite.cmake--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org Calligra Suite:
: A graphic art and office suite - http://calligra.orgKexi:
: A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-usersThis email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-usersThis email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 10/8/2015 11:51 AM, Marc L. Allen wrote:
> However, CTE is a functionality enhancement that, I believe, does not impact the ability of previous SQLite versions to work with the database.
One could create a view, or a trigger, that uses CTE query. That's not
backward-compatible. Basically, any query could in principle become part
of the schema.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 10/8/15, Marc L. Allen < [hidden email]> wrote:
> However, CTE is a functionality enhancement that, I believe, does not impact
> the ability of previous SQLite versions to work with the database. The
> thing is, I don't believe CTE is simply a "performance enhancement." To me,
> a "performance enhancement" provides no new functionality, but just works
> better.
>
If someone does (for example):
CREATE VIEW digits AS
WITH RECURSIVE c(x) AS (VALUES(0) UNION ALL SELECT x+1 FROM c WHERE x<9)
SELECT x FROM c;
Then the CTE becomes part of the schema, and the database cannot be
opened by an earlier version of SQLite that lacks support for CTEs.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
I'm indifferent, to be quite honest, how the version numbers work and what
I download, so long that there is a difference and things become more solid
with both enhancements and fixes.. Set the file name and revisions to a
date, for all that it matters to me, or just label is as
SQLite3.dll/.zip/.so/.etc. But I'm kind of siding on what Marc is getting
at.
Lets say that a new function is added. Y gets bumped to Y+1 (Call it Y1)
and Z is reset to 0.
Another new function is added, Y gets bumped again to Y+1 (Call it Y2) and
Z is again reset to 0 and now Y1 is considered irrelevant.
What happens when something is discovered wrong with the first function?
This update to the function introduced in Y1 doesn't have anything to do
with Y2, so is Z going to get bumped?
(This is my personal general conundrum with how team based revision systems
work with GIT, SVN, and now even Fossil. If something found new today that
was introduced three revisions ago, whats the count get set to?)
My $0.02 comes down to scrap the whole major/minor/build version system and
go with something more concrete using build dates. So 3.201508151235.
This would point that 3 is for file structure for SQLite3 while the build
date contains whatever has been put into code. At the source code level
for individual files, my SCR automatically bumps up the version number.
All in all, with single or multiple changes, only affects the final output
of the build process.
What the minor and build versions mean is subject to change and offer an
air of confusion. With a 3.{Date} version, you get a concrete "This is the
day the product was built with all features and known bug fixes". And it'd
be just as easy for people to report "Between 201510081205 and 201512101500
I have this problem..." Bit harder to read, come to think of it.....
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
To look at it another way, in version X.Y.Z, it has always been the
case and will remain the case that Y is incremented for major changes
and Z is incremented for minor changes. The proposed policy change is
to alter the definition of "major" and "minor" such that *anything*
other than a simple bug fix of a few lines is considered a "major"
change. Formerly, "major" changes were things like adding WAL mode or
rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
and partial indexes were all considered "minor" changes.
It all really boils down to this: What is the difference between a
"major" and a "minor" change?
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin < [hidden email]> wrote:
>
> On 8 Oct 2015, at 2:38pm, Richard Hipp < [hidden email]> 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-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 10/8/15, Stephen Chrzanowski < [hidden email]> wrote:
>
> What the minor and build versions mean is subject to change and offer an
> air of confusion. With a 3.{Date} version, you get a concrete "This is the
> day the product was built with all features and known bug fixes". And it'd
> be just as easy for people to report "Between 201510081205 and 201512101500
> I have this problem..." Bit harder to read, come to think of it.....
SQLite already offers date-based versioning as an alternative. See
the sqlite3_sourceid() interface and the SQLITE_SOURCE_ID macro, both
of which begin with the ISO8601 date.
The sqlite3_libversion_number() interface and the
SQLITE_VERSION_NUMBER macro depend on the old-style X.Y.Z version
numbers though. And lots of legacy code depends on those interfaces,
so they need to continue to be supported moving forward.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On Thu, Oct 8, 2015 at 10:21 AM, Richard Hipp < [hidden email]> wrote:
> To look at it another way, in version X.Y.Z, it has always been the
> case and will remain the case that Y is incremented for major changes
> and Z is incremented for minor changes. The proposed policy change is
> to alter the definition of "major" and "minor" such that *anything*
> other than a simple bug fix of a few lines is considered a "major"
> change. Formerly, "major" changes were things like adding WAL mode or
> rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
> and partial indexes were all considered "minor" changes.
>
> It all really boils down to this: What is the difference between a
> "major" and a "minor" change?
>
A "minor" change has to my way of thinking always been about "this fixes
something that wasn't working as intended".
One potential downside (based on a previous comment in this thread) I can
see to going to a more "semantic versioning compliant" model is the
expectation that some people might have that every 3.y release will be
maintained with bug fixes / z level patches. For example:
3.1.0 is released
3.1.1 fixes a bug in 3.1
3.2.0 is released with new features.
3.2.1 fixes a bug originally introduced in 3.1.0
Some people are going to expect that bug fix to be back ported into the 3.1
branch and have a 3.1.2 release cut from it.
--
Scott Robison
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
Ah. Of course.
Thanks for waking me up.. both you and Igor.
-----Original Message-----
From: [hidden email] [mailto: [hidden email]] On Behalf Of Richard Hipp
Sent: Thursday, October 08, 2015 12:12 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested
On 10/8/15, Marc L. Allen < [hidden email]> wrote:
> However, CTE is a functionality enhancement that, I believe, does not
> impact the ability of previous SQLite versions to work with the
> database. The thing is, I don't believe CTE is simply a "performance
> enhancement." To me, a "performance enhancement" provides no new
> functionality, but just works better.
>
If someone does (for example):
CREATE VIEW digits AS
WITH RECURSIVE c(x) AS (VALUES(0) UNION ALL SELECT x+1 FROM c WHERE x<9)
SELECT x FROM c;
Then the CTE becomes part of the schema, and the database cannot be opened by an earlier version of SQLite that lacks support for CTEs.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-usersThis email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
I'd add the disclaimer to the page that once 3.2.0 is built, 3.1.x becomes
inert and any fixes pertaining to that particular release belongs to the
3.2.* release. "Lawyer speak", I guess one could coin it.
What the "Effect Definition" is of what Major and Minor is, I think Richard
draft page has it. If a database made today can't be open by tomorrows
release, then Y+1;Z=0, otherwise, Z+1. If something was found to be broken
in Y-5 and now fixed, then the new build would be just Z+1.
2050.... Seems just around the corner....
On Thu, Oct 8, 2015 at 12:32 PM, Scott Robison < [hidden email]>
wrote:
> On Thu, Oct 8, 2015 at 10:21 AM, Richard Hipp < [hidden email]> wrote:
>
> > To look at it another way, in version X.Y.Z, it has always been the
> > case and will remain the case that Y is incremented for major changes
> > and Z is incremented for minor changes. The proposed policy change is
> > to alter the definition of "major" and "minor" such that *anything*
> > other than a simple bug fix of a few lines is considered a "major"
> > change. Formerly, "major" changes were things like adding WAL mode or
> > rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
> > and partial indexes were all considered "minor" changes.
> >
> > It all really boils down to this: What is the difference between a
> > "major" and a "minor" change?
> >
>
> A "minor" change has to my way of thinking always been about "this fixes
> something that wasn't working as intended".
>
> One potential downside (based on a previous comment in this thread) I can
> see to going to a more "semantic versioning compliant" model is the
> expectation that some people might have that every 3.y release will be
> maintained with bug fixes / z level patches. For example:
>
> 3.1.0 is released
> 3.1.1 fixes a bug in 3.1
> 3.2.0 is released with new features.
> 3.2.1 fixes a bug originally introduced in 3.1.0
>
> Some people are going to expect that bug fix to be back ported into the 3.1
> branch and have a 3.1.2 release cut from it.
>
> --
> Scott Robison
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 10/8/15, Scott Robison < [hidden email]> wrote:
>
> 3.1.0 is released
> 3.1.1 fixes a bug in 3.1
> 3.2.0 is released with new features.
> 3.2.1 fixes a bug originally introduced in 3.1.0
>
> Some people are going to expect that bug fix to be back ported into the 3.1
> branch and have a 3.1.2 release cut from it.
>
The SQLite developers are happy to do this kind of backporting at the
request of SQLite Consortium members and Technical Support customers.
;-)
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On Thu, Oct 8, 2015 at 10:53 AM, Richard Hipp < [hidden email]> wrote:
> On 10/8/15, Scott Robison < [hidden email]> wrote:
> >
> > 3.1.0 is released
> > 3.1.1 fixes a bug in 3.1
> > 3.2.0 is released with new features.
> > 3.2.1 fixes a bug originally introduced in 3.1.0
> >
> > Some people are going to expect that bug fix to be back ported into the
> 3.1
> > branch and have a 3.1.2 release cut from it.
> >
>
> The SQLite developers are happy to do this kind of backporting at the
> request of SQLite Consortium members and Technical Support customers.
> ;-)
>
Well of course! But this is the internet, everything is supposed to be free
and exactly as you want it! :)
--
Scott Robison
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 2015-10-08 06:21 PM, Richard Hipp wrote:
> It all really boils down to this: What is the difference between a
> "major" and a "minor" change?
>
Agreed, and the decision between whether an item is major or minor is
always going to be a blurred line. It is not important for the issue at
hand either, the decision on reshaping the scheme simply has to cater
for how to present the version once a major or minor change is
registered. The guidelines on how to decide whether a change is "major"
or "minor" is an important but different conversation, and probably
already rather well-defined (or at least: mostly agreed upon).
I think the scheme proposed is great and will fit most general cases -
no doubt somebody somewhere will have a need at a tangent, but the
proposed definitely services the questions and ideals to date.
Also, thank you kindly for the efforts toward this.
+1 for the new scheme.
Ryan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
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-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
|
|
On 10/8/15, Darren Duncan < [hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
|
12
|
Locked
