[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
All the extensions have to be explicitly enabled by compile-time flags. This is the case for FTS3/4, which has been included in the amalgamation for several years. The RTree and also the new JSON extension are included as well. It only seems logical that FTS5 should be included too as it is part of official releases. F. On Thu, Oct 8, 2015 at 4:01 PM, Hick Gunter wrote: > I expect users running SQLite on embedded devices would be thrilled... > > -Urspr?ngliche Nachricht- > Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto: > sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Filip Navara > Gesendet: Donnerstag, 08. Oktober 2015 15:55 > An: sqlite-dev at mailinglists.sqlite.org > Cc: General Discussion of SQLite Database > Betreff: Re: [sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing > > Would it be possible to include FTS5 in the amalgamation? > > Thanks, > Filip Navara > > On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp wrote: > > > The release checklist for version 3.8.12 > > (https://www.sqlite.org/checklists/3081200/index) is now active. The > > 3.8.12 release will occur when the checklist goes all-green. > > > > A preliminary change log for version 3.8.12 can be seen at > > https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary > > documentation can be seen at https://www.sqlite.org/draft/ > > > > If you have issues or concerns with the current SQLite trunk, please > > speak up *now*. > > > > -- > > D. Richard Hipp > > drh at sqlite.org > > ___ > > sqlite-dev mailing list > > sqlite-dev at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev > > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ___ > Gunter Hick > Software Engineer > Scientific Games International GmbH > FN 157284 a, HG Wien > Klitschgasse 2-4, A-1130 Vienna, Austria > Tel: +43 1 80100 0 > E-Mail: hick at scigames.at > > This communication (including any attachments) is intended for the use of > the intended recipient(s) only and may contain information that is > confidential, privileged or legally protected. Any unauthorized use or > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please immediately notify the sender > by return e-mail message and delete all copies of the original > communication. Thank you for your cooperation. > > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
Would it be possible to include FTS5 in the amalgamation? Thanks, Filip Navara On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp wrote: > The release checklist for version 3.8.12 > (https://www.sqlite.org/checklists/3081200/index) is now active. The > 3.8.12 release will occur when the checklist goes all-green. > > A preliminary change log for version 3.8.12 can be seen at > https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary > documentation can be seen at https://www.sqlite.org/draft/ > > If you have issues or concerns with the current SQLite trunk, please > speak up *now*. > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-dev mailing list > sqlite-dev at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev >
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
I expect users running SQLite on embedded devices would be thrilled... -Urspr?ngliche Nachricht- Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Filip Navara Gesendet: Donnerstag, 08. Oktober 2015 15:55 An: sqlite-dev at mailinglists.sqlite.org Cc: General Discussion of SQLite Database Betreff: Re: [sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing Would it be possible to include FTS5 in the amalgamation? Thanks, Filip Navara On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp wrote: > The release checklist for version 3.8.12 > (https://www.sqlite.org/checklists/3081200/index) is now active. The > 3.8.12 release will occur when the checklist goes all-green. > > A preliminary change log for version 3.8.12 can be seen at > https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary > documentation can be seen at https://www.sqlite.org/draft/ > > If you have issues or concerns with the current SQLite trunk, please > speak up *now*. > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-dev mailing list > sqlite-dev at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev > ___ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: hick at scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
On 7 October 2015 at 17:39, Richard Hipp wrote: > On 10/7/15, Jaroslaw Staniek wrote: > > ? would you elaborate what? is the > > benefit of using x.y.z versioning scheme if so many new features come to > > the "z" release? > > That's the versioning scheme that has been used by SQLite for 15 > years. Back when it was adopted, 15 years ago, it was certainly *not* > the case that 99.9% of software did something different. In fact, 15 > years ago, the current SQLite versioning scheme was rather common. > > The community seems to want the second number (current 8) to increment > every time a new feature is added to SQLite. I will take your request > under advisement. Realize, however, that had the current preferred > number scheme been used for SQLite from the beginning, the next > release would be called 3.112. > > ? Thanks so much, such a linear version would be appreciated. PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1 -- I think versions x.y.z.v would be no longer needed. ? -- 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] [sqlite-dev] SQLite version 3.8.12 enters testing
On Wed, Oct 7, 2015 at 5:39 PM, Richard Hipp wrote: > On 10/7/15, Jaroslaw Staniek wrote: > > ? would you elaborate what? is the > > benefit of using x.y.z versioning scheme if so many new features come to > > the "z" release? > > [...] The community seems to want the second number (current 8) to > increment > every time a new feature is added to SQLite. I will take your request > under advisement. Realize, however, that had the current preferred > number scheme been used for SQLite from the beginning, the next > release would be called 3.112. > That 3.112 version is a better reflection of all the changes in a way. Minor version bumps are kinda arbitrary, why 3.8.12 and not 3.9.0 indeed. Table-valued functions are a big enough change to warrant it IMHO, but maybe that's just me. --DD
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
? ? On 7 October 2015 at 16:42, Richard Hipp wrote: > The release checklist for version 3.8.12 > (https://www.sqlite.org/checklists/3081200/index) is now active. The > 3.8.12 release will occur when the checklist goes all-green. > > A preliminary change log for version 3.8.12 can be seen at > https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary > documentation can be seen at https://www.sqlite.org/draft/ > > If you have issues or concerns with the current SQLite trunk, please > speak up *now*. > > ?Hi?, ?Thanks for the great work! PS: I am sorry to repeat that once more but based on the extensive list of new features in this "minor release": would you elaborate what? is the benefit of using x.y.z versioning scheme if so many new features come to the "z" release? I've heard that "Users are expected to compile sqlite by hand" but as we all know Linux distributions ship them and reject apps that own a copy of SQLite. Then when some projects start to depend on features that came in 3.8.12, distributions do not seem to care about that. Any 3.8.z is considered compatible. This is how 99.(9)% of software is versioned. For now users won't notice that <=3.8.12 is installed, and checking of that is delegated to the each application's runtime or to the specific packaging rules. So is there any hope for 3.9 or 4.x to have more traditional versioning: having a distinction between patch releases and minor releases, where only the latter allows for new features? SQLite evolves so quickly that I know we would have version like 3.40.z by now. And that would be much better... -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-dev mailing list > sqlite-dev at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev > -- 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] [sqlite-dev] SQLite version 3.8.12 enters testing
On 7 Oct 2015, at 4:39pm, Richard Hipp wrote: > The community seems to want the second number (current 8) to increment > every time a new feature is added to SQLite. I will take your request > under advisement. Realize, however, that had the current preferred > number scheme been used for SQLite from the beginning, the next > release would be called 3.112. To supplement Richard's answer ... The three-number versioning scheme works like this. Suppose your software is currently on version 2.2.2 . The next version would be 2.2.3 -- purely a bugfix with no new features introduced 2.3.0 -- introduces a new feature (even if it fixes a bug too) 3.0.0 -- a major rewrite (whether or not it introduces new features) This system is still in use in many software publishers. SQLite doesn't use it in quite the same way because (A) The parsing and optimization parts of SQLite are extremely complicated and can make it difficult to distinguish between a bug-fix and a minor new feature. (B) The product itself is called SQLite3 so the '3' has to be fixed. Major rewrites to SQLite to, for example, introduce WAL mode, can't change the '3'. Simon.
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
"Scott Robison" wrote... > On Wed, Oct 7, 2015 at 2:06 PM, Jaroslaw Staniek wrote: > >> >> >> On 7 October 2015 at 17:39, Richard Hipp wrote: >> >>> On 10/7/15, Jaroslaw Staniek wrote: >>> > ? would you elaborate what? is the >>> > benefit of using x.y.z versioning scheme if so many new features come >>> > to >>> > the "z" release? >>> >>> That's the versioning scheme that has been used by SQLite for 15 >>> years. Back when it was adopted, 15 years ago, it was certainly *not* >>> the case that 99.9% of software did something different. In fact, 15 >>> years ago, the current SQLite versioning scheme was rather common. >>> >>> The community seems to want the second number (current 8) to increment >>> every time a new feature is added to SQLite. I will take your request >>> under advisement. Realize, however, that had the current preferred >>> number scheme been used for SQLite from the beginning, the next >>> release would be called 3.112. >>> >>> >> Thanks so much, such a linear version would be appreciated. >> >> PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1 >> -- I think versions x.y.z.v would be no longer needed. >> > > Really, the SQLite3 versioning isn't that far off from Semantic > Versioning. > Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH. > > Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading > through the release history it is fairly clear that a change in MAJOR > usually results from MAJOR new functionality, MINOR is for relatively > MINOR > new functionality, and PATCH is apparently never used outside that > context. > > While I personally have no complaints with people who use Semantic > Versioning, I don't see SQLite versioning as being horribly incompatible > with it. In fact, if I were making the decision, I'd keep the current > versioning. I agree. Keep the same versioning schema. jic
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
On Wed, Oct 7, 2015 at 2:06 PM, Jaroslaw Staniek wrote: > > > On 7 October 2015 at 17:39, Richard Hipp wrote: > >> On 10/7/15, Jaroslaw Staniek wrote: >> > ? would you elaborate what? is the >> > benefit of using x.y.z versioning scheme if so many new features come to >> > the "z" release? >> >> That's the versioning scheme that has been used by SQLite for 15 >> years. Back when it was adopted, 15 years ago, it was certainly *not* >> the case that 99.9% of software did something different. In fact, 15 >> years ago, the current SQLite versioning scheme was rather common. >> >> The community seems to want the second number (current 8) to increment >> every time a new feature is added to SQLite. I will take your request >> under advisement. Realize, however, that had the current preferred >> number scheme been used for SQLite from the beginning, the next >> release would be called 3.112. >> >> ? > Thanks so much, such a linear version would be appreciated. > > PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1 > -- I think versions x.y.z.v would be no longer needed. > Really, the SQLite3 versioning isn't that far off from Semantic Versioning. Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH. Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading through the release history it is fairly clear that a change in MAJOR usually results from MAJOR new functionality, MINOR is for relatively MINOR new functionality, and PATCH is apparently never used outside that context. While I personally have no complaints with people who use Semantic Versioning, I don't see SQLite versioning as being horribly incompatible with it. In fact, if I were making the decision, I'd keep the current versioning. -- Scott Robison
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
On 10/7/15, Simon Slavin wrote: > (B) The product itself is called SQLite3 so the '3' has to be fixed. Major > rewrites to SQLite to, for example, introduce WAL mode, can't change the > '3'. The "3" is the file format. SQLite1 and SQLite2 used different and incompatible file formats. SQLite 3.8.12 can read and write any database made by any prior version of SQLite. SQLite 3.0.0 can read and write any database made by any subsequent version of SQLite, as long as no new features (ex: common table expressions, partial indexes) are used. (In practice, so many new features have been added since 3.0.0 that it will be difficult to find a real database that 3.0.0 can read and write, but it is possible in theory.) -- D. Richard Hipp drh at sqlite.org
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
On 10/7/15, Jaroslaw Staniek wrote: > ? would you elaborate what? is the > benefit of using x.y.z versioning scheme if so many new features come to > the "z" release? That's the versioning scheme that has been used by SQLite for 15 years. Back when it was adopted, 15 years ago, it was certainly *not* the case that 99.9% of software did something different. In fact, 15 years ago, the current SQLite versioning scheme was rather common. The community seems to want the second number (current 8) to increment every time a new feature is added to SQLite. I will take your request under advisement. Realize, however, that had the current preferred number scheme been used for SQLite from the beginning, the next release would be called 3.112. -- D. Richard Hipp drh at sqlite.org
[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
On Wed, Oct 7, 2015 at 9:05 AM, Dominique Devienne wrote: > On Wed, Oct 7, 2015 at 5:39 PM, Richard Hipp wrote: > > On 10/7/15, Jaroslaw Staniek wrote: > > > ? would you elaborate what? is the > > > benefit of using x.y.z versioning scheme if so many new features come > to > > > the "z" release? > > > > [...] The community seems to want the second number (current 8) to > > increment > > every time a new feature is added to SQLite. I will take your request > > under advisement. Realize, however, that had the current preferred > > number scheme been used for SQLite from the beginning, the next > > release would be called 3.112. > > > > That 3.112 version is a better reflection of all the changes in a way. > > Minor version bumps are kinda arbitrary, Having been involved in open source and commercial software for 25 years, by now I've figured out that version numbers are themselves kinda arbitrary. I honestly don't think that the SQLite mailing list having this tired old discussion is going to shed any new light on the issue or result in a system which pleases everyone. There is no chance that the version number is going to become a standardized reliable form out out-of-band messaging. If you care about what's in there, you're going to have to pay attention to what's in there. -scott
