Documentation Source Text

Check-in [82a2560a88]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Proposed new version numbering scheme.
Timelines: family | ancestors | descendants | both | new-version-numbering
Files: files | file ages | folders
SHA1: 82a2560a889d2a2895f44bc37b4179b66df1e49a
User & Date: drh 2015-10-08 13:29:52
Context
2015-10-09
14:00
Update the documentation for the version numbering change. check-in: 4fc9d7ce50 user: drh 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
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

14
15
16
17
18
19
20
21




22
23
24
25
26
27
28
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.8.12)} {




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







|
>
>
>
>







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
145
146
</ol>


<h2>Compatibility</h2>

<p>
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
expressions will not be usable by earlier versions of SQLite.







|

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
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_8_12.html">Version 3.8.12</a>
of SQLite is recommended for all new development.
</li>
</ul></p>

<h3>Common Links</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
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.8.12].
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>







|







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.