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: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Jaroslaw Staniek Sent: Thursday, October 08, 2015 11:33 AM To: sqlite-dev at mailinglists.sqlite.org 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 <drh at sqlite.org> 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 sqlite-users at mailinglists.sqlite.org 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.
