Index: pages/changes.in ================================================================== --- pages/changes.in +++ pages/changes.in @@ -16,11 +16,15 @@ global nChng aChng set aChng($nChng) [list $date $desc $options] incr nChng } -chng {2015-11-01 (3.8.12)} { +chng {2015-11-01 (3.9.0)} { +

Policy Changes: +

  • The [version numbering conventions] for SQLite are revised, beginning in this + release, to always use a 3-number version in which the second number increments + whenever there are new SQL language features and/or C/C++ interfaces.

    New Features And Enhancements:

  • Added [the json1 extension] module in the source tree.
  • The [CREATE VIEW] statement now accepts an optional list of column names following the view name.
  • Added support for [indexes on expressions]. Index: pages/expridx.in ================================================================== --- pages/expridx.in +++ pages/expridx.in @@ -140,7 +140,7 @@

    Compatibility

    The ability to index expressions was added to SQLite with -[version 3.8.12] in October of 2015. A database that uses an index on +[version 3.9.0] in October of 2015. A database that uses an index on expressions will not be usable by earlier versions of SQLite. Index: pages/index.in ================================================================== --- pages/index.in +++ pages/index.in @@ -85,11 +85,11 @@

    Current Status

    Common Links

    Index: pages/lang.in ================================================================== --- pages/lang.in +++ pages/lang.in @@ -782,11 +782,11 @@ and may not use subqueries nor functions whose result might change (ex: [random()] or [sqlite_version()]). ^Expressions in an index may only refer to columns in the table that is being indexed. Indexes on expression will not work with versions of SQLite prior -to [version 3.8.12]. +to [version 3.9.0]. See the [Indexes On Expressions] document for additional information about using general expressions in CREATE INDEX statements.

    There are no arbitrary limits on the number of indices that can be attached to a single table. ^(The number of columns in an index is ADDED pages/versionnumbers.in Index: pages/versionnumbers.in ================================================================== --- /dev/null +++ pages/versionnumbers.in @@ -0,0 +1,85 @@ +hd_keywords {version numbering conventions} +Version Numbers in SQLite + +

    SQLite Version Numbers

    + +

    +There are two strategies for version numbers in SQLite. +The historical system, in use from the first release on 2000-08-17 +though version 3.8.11.1 on 2015-07-29, employed a version that +contained between two and four numbers. +Beginning with [version 3.9.0], the version numbering system +was revised so that version number always contain exactly 3 numbers. + +

    The New Version Numbering System (After 2015-10-01)

    + +

    +All SQLite releases starting with 3.9.0 use a three-number version +of the form X.Y.Z. +The first number X is only increased when there is a change that +breaks backwards compatibility of the database file format. The +current value for X is 3, and the SQLite developers plan to support +the current file format through at least the year 2050. Hence, one +can expect that all future versions of SQLite for the next several +decades will begin with "3.". + +

    +The second number Y is incremented for any change that breaks forwards +compatibility by adding new features, either in the file format +or in the C/C++ interface. +Most SQLite releases moving forward are expected +to increment the second number Y. The Z is reset to zero whenever Y +is increased. + +

    +The third number Z is incremented for releases consisting of only +performance enhancements and bug fixes. + +

    +The rate of enhancement for SQLite over the previous five years +(2010-2015) is approximately 6 increments of Y per year. The +numbering format used by for [SQLITE_VERSION_NUMBER] and +[sqlite3_libversion_number()] allows versions up to 3.999.999, which is +more than enough for the planned end-of-support date for SQLite +in 2050. 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. + +

    The Historical Numbering System (Before 2015-10-01)

    + +

    This historical version numbering system used a two-, three-, +or four-number version: W.X, W.X.Y, or W.X.Y.Z. +W was the file format: 1 or 2 or 3. +X was the major version. +Y was the minor version. +Z was used only for patch releases to fix bugs. + +

    +There have been three historical file formats for SQLite. +SQLite 1.0 through 1.0.32 used the +[https://www.gnu.org/software/gdbm/gdbm.html|gdbm] library as its storage +engine. +SQLite 2.0.0 through 2.8.17 used a custom b-tree storage engine that +supported only text keys and data. +All modern versions of SQLite (3.0.0 to present) use a b-tree storage +engine that has full support for binary data and Unicode. + +

    +This major version number X was historically incremented only for +large and important changes to the code. What constituted "large +and important" was subjective. The 3.6.23 to 3.7.0 change +was a result of adding support for [WAL mode]. +The 3.7.17 to 3.8.0 change was a result of rewrite known as the +[next generation query planner]. + +

    +The minor version number Y was historically incremented for new +features and/or new interfaces that did not significantly change +the structure of the code. The addition of [common table expressions], +[partial indexes], and [indexes on expressions] are all examples of +"minor" changes. Again, the destinction between "major" and "minor" +is subjective. + +

    +The patch level Z was historically only used for bug-fix releases +that changed only a small number of code lines.