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
