Artifact
d046ec30f9003d7697054243dfbc827e036762beccfcd741219bcb7a1789f3d0:
- File
pages/versionnumbers.in
— part of check-in
[1a236e279d]
at
2018-05-31 17:37:17
on branch trunk
— Miscellaneous typo fixes and minor enhancements.
(user:
drh
size: 3458)
<tcl>hd_keywords {version numbering conventions}</tcl>
<title>Version Numbers in SQLite</title>
<fancy_format>
<h1>SQLite Version Numbers</h1>
<p>
Beginning with [version 3.9.0] ([dateof:3.9.0]) SQLite uses
[http://semver.org|semantic versioning].
Prior to that time, SQLite employed a version identifier that
contained between two and four numbers.
<h2>The New Version Numbering System (After [dateof:3.9.0])</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 backward compatibility. The
current value for X is 3, and the SQLite developers plan to support
the current SQLite database file format, SQL syntax, and C interface
through [long term support|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 forward
compatibility by adding new features.
Most future SQLite releases 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 [dateof:3.9.0])</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 distinction 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.
<h2>Version History</h2>
<ul>
<li>[chronology|Chronology]
<li>[release history|Change log]
</ul>