Documentation Source Text

set nChng 0
proc chng {date desc {options {}}} {
  global nChng aChng
  set aChng($nChng) [list $date $desc $options]
  incr nChng
}

chng {2015-11-01 (3.9.0)} {
<p><b>Policy Changes:</b>
<li>The [version numbering conventions] for SQLite are revised to use the
    emerging standard of [http://semver.org/|semantic versioning].
<p><b>New Features And Enhancements:</b>
<li>Added [the json1 extension] module in the source tree.
<li>The [CREATE VIEW] statement now accepts an optional list of
    column names following the view name.
<li>Added support for [indexes on expressions].
<li>Added support for [table-valued functions] in the FROM clause of a
    [SELECT] statement.

</ol>


<h2>Compatibility</h2>

<p>
The ability to index expressions was added to SQLite with 
[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.

</td>
<td width="20"></td><td bgcolor="#044a64" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>
<li><a href="releaselog/3_9_0.html">Version 3.9.0</a>
of SQLite is recommended for all new development.
</li>
</ul></p>

<h3>Common Links</h3>

<p><ul>

<tcl>hd_fragment indexexpr</tcl>
<p>^Expressions in an index may not reference other tables
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.9.0].
See the [Indexes On Expressions] document for additional information
about using general expressions in CREATE INDEX statements.

<p>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 
limited to the value set by
[sqlite3_limit]([SQLITE_LIMIT_COLUMN],...).)^</p>

<tcl>hd_keywords {version numbering conventions}</tcl>
<title>Version Numbers in SQLite</title>

<h1>SQLite Version Numbers</h1>

<p>
Beginning with [version 3.9.0] SQLite uses 
[http://semver.org|semantic versioning].
Prior to that time, SQLlite employed a version identifier that
contained between two and four numbers.

<h2>The New Version Numbering System (After 2015-10-01)</h2>

<p>
All SQLite releases starting with 3.9.0 use a three-number
"[http://semver.org|semantic version]" of the form X.Y.Z.
The first number X is only increased when there is a change that
breaks backwards compatibility.  The
current value for X is 3, and the SQLite developers plan to support
the current SQLite databse file format, SQL syntax, and C interface
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.".

<p>
The second number Y is incremented for any change that breaks forwards
compatibility by adding new features.
Most SQLite releases moving forward are expected
to increment the second number Y.  The Z is reset to zero whenever Y
is increased.

<p>
The third number Z is incremented for releases consisting of only
small changes that implement performance enhancements and/or bug fixes.

<p>
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.

<h2>The Historical Numbering System (Before 2015-10-01)</h2>

<p>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.

<p>
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.

<p>
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].

<p>
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.

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