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>