Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch new-version-numbering Excluding Merge-Ins
This is equivalent to a diff from 543413f753 to 82a2560a88
2015-10-09
| ||
14:00 | Update the documentation for the version numbering change. (check-in: 4fc9d7ce50 user: drh tags: trunk) | |
12:09 | Fix typos in fts5.in. (check-in: cc68da99a4 user: dan tags: trunk) | |
2015-10-08
| ||
13:29 | Proposed new version numbering scheme. (Closed-Leaf check-in: 82a2560a88 user: drh tags: new-version-numbering) | |
00:21 | Minor English grammar changes. (check-in: 543413f753 user: drh tags: trunk) | |
2015-10-07
| ||
22:42 | Fix a couple typos in the new docs. (check-in: 255ed0fac7 user: mistachkin tags: trunk) | |
Changes to pages/changes.in.
︙ | ︙ | |||
14 15 16 17 18 19 20 | set nChng 0 proc chng {date desc {options {}}} { global nChng aChng set aChng($nChng) [list $date $desc $options] incr nChng } | | > > > > | 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 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, 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. <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. |
︙ | ︙ |
Changes to pages/expridx.in.
︙ | ︙ | |||
138 139 140 141 142 143 144 | </ol> <h2>Compatibility</h2> <p> The ability to index expressions was added to SQLite with | | | 138 139 140 141 142 143 144 145 146 | </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. |
Changes to pages/index.in.
︙ | ︙ | |||
83 84 85 86 87 88 89 | </td> <td width="20"></td><td bgcolor="#044a64" width="1"></td><td width="20"></td> <td valign="top"> <h3>Current Status</h3> <p><ul> | | | 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 | </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> |
︙ | ︙ |
Changes to pages/lang.in.
︙ | ︙ | |||
780 781 782 783 784 785 786 | <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 | | | 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 | <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> |
︙ | ︙ |
Added pages/versionnumbers.in.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | <tcl>hd_keywords {version numbering conventions}</tcl> <title>Version Numbers in SQLite</title> <h1>SQLite Version Numbers</h1> <p> 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. <h2>The New Version Numbering System (After 2015-10-01)</h2> <p> 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.". <p> 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. <p> The third number Z is incremented for releases consisting of only performance enhancements and 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. |