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 [hidden email] _______________________________________________ sqlite-users mailing list [hidden email] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users |
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-----
3.9.0) since
> 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 > 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 |
In reply to this post by Richard Hipp-3
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.org Kexi: : 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-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.org Kexi: : 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-users This 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.org Kexi: : 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-users This 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 This 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 |
In reply to this post by Marc L. Allen
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 |
In reply to this post by Marc L. Allen
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 |
In reply to this post by Marc L. Allen
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 |
In reply to this post by Richard Hipp-3
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 |
In reply to this post by Simon Slavin-3
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 |
In reply to this post by Stephen Chrzanowski
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 |
In reply to this post by Richard Hipp-3
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 |
In reply to this post by Richard Hipp-3
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-users This 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 |
In reply to this post by Scott Robison-2
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 |
In reply to this post by Scott Robison-2
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 |
In reply to this post by Richard Hipp-3
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 |
In reply to this post by Richard Hipp-3
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 |
Free forum by Nabble | Edit this page |