Documentation Source Text

Check-in [db4a43fe7d]
Login

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

Overview
Comment:Add the "Long-term Support" document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:db4a43fe7dd2dcb7b8e15e9b3d9881caf435253b
User & Date: drh 2016-09-27 19:56:13
Context
2016-09-27
20:09
Tweaks to long-term support. check-in: 8724e4b982 user: drh tags: trunk
19:56
Add the "Long-term Support" document. check-in: db4a43fe7d user: drh tags: trunk
18:26
On the About page, change the "common links" sidebar into "Executive summary" check-in: feebb52d8a user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/about.in.

15
16
17
18
19
20
21

22
23
24
25
26
27
28
     (2<sup><small>47</small></sup> bytes)
<li> Max row size: <a href='limits.html'>1 gigabyte</a>
<li> <a href='testing.html'>Aviation-grade quality and testing</a>
<li> <a href='zeroconf.html'>Zero-configuration</a>
<li> <a href='transactional.html'>ACID transactions, even after power loss</a>
<li> <a href='fileformat.html'>Stable, enduring file format</a>
<li> <a href='doclist.html'>Extensive, detailed documentation</a>

</div>

<p>SQLite is an in-process library that implements a
<a href="selfcontained.html">self-contained</a>, 
<a href="serverless.html">serverless</a>,
<a href="zeroconf.html">zero-configuration</a>,
<a href="transactional.html">transactional</a>







>







15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
     (2<sup><small>47</small></sup> bytes)
<li> Max row size: <a href='limits.html'>1 gigabyte</a>
<li> <a href='testing.html'>Aviation-grade quality and testing</a>
<li> <a href='zeroconf.html'>Zero-configuration</a>
<li> <a href='transactional.html'>ACID transactions, even after power loss</a>
<li> <a href='fileformat.html'>Stable, enduring file format</a>
<li> <a href='doclist.html'>Extensive, detailed documentation</a>
<li> <a href='lts.html'>Long-term support</a>
</div>

<p>SQLite is an in-process library that implements a
<a href="selfcontained.html">self-contained</a>, 
<a href="serverless.html">serverless</a>,
<a href="zeroconf.html">zero-configuration</a>,
<a href="transactional.html">transactional</a>

Added pages/lts.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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
<title>Long Term Support</title>
<tcl>hd_keywords {long term support}</tcl>

<fancy_format>

<p>
The intent of the developers is to support SQLite through
the year 2050.

<p>
At this writing, 2050 is still 34 years in the future.
Nobody knows what will happen in that time, and we cannot
absolutely promise that SQLite will be viable or useful that
far out.
But we can promise this: we plan as if we will be
supporting SQLite until 2050.
That long-term outlook affects our
decisions in important ways.

<ul>
<li><p>
<b>Sustainable business model</b> &rarr;
The company behind SQLite (Hipp, Wyrick &amp; Company, Inc., "Hwaci")
is closely held, has low fixed costs, and zero debt.
There are no VCs to pay off.
There is no "exit strategy".
Hwaci is a 24-year-old engineering-only company, with no
marketing or sales divisions.
We are here for the long-haul and
will be available to you when you need us.

<li><p>
<b>Cross-platform</b> &rarr;
SQLite runs on any platform with an 8-bit byte,
two's complement 32-bit and 64-bit integers, 
and a C compiler.  It is actively
tested on all currently popular CPUs and operating
systems.  The extreme portability of the SQLite code will
help it remain viable on future platforms.

<li><p>
<b><a href="testing.html">Aviation-grade testing</a></b> &rarr;
Every machine-code branch instruction is tested in both
directions.  Multiple times.  On multiple platforms and with
multiple compilers.  This helps make the code robust for
future migrations.  The intense testing also means that new
developers can make experimental enhancements to SQLite and,
assuming legacy tests all pass, be reasonably sure that the
enhancement does not break legacy.

<li><p>
<b>Extensive, detailed documentation</b> &rarr;
SQLite has candid, developer-friendly,
and open-source documentation.  Docs are written by and
for programmers.
(A few examples:
<a href="./arch.html">[1]</a>
<a href="./fileformat.html">[2]</a>
<a href="./queryplanner.html">[3]</a>
<a href="./opcode.html">[4]</a>
<a href="./compile.html">[5]</a>
<a href="./malloc.html">[6]</a>
<a href="./debugging.html">[7]</a>
<a href="./howtocorrupt.html">[8]</a>)
The extension documentation helps new developers
come up to speed on SQLite very quickly.

<li><p>
<b>Heavily commented source code</b> &rarr;
The SQLite source code is over 35% comment.  Not boiler-plate
comments, but useful comments that explain the meaning of variables
and objects and the intent of methods and procedures.  
The code is designed
to be accessible to new programmers and maintainable over a span
of decades.

<li><p>
<b>Disaster planning</b> &rarr;
Every byte of source-code history for SQLite is cryptographically
protected and is automatically replicated to multiple
geographically separated servers, in datacenters 
owned by different companies.
Thousands of additional clones exist on private servers around the
world.
The primary developers of SQLite are all in excellent health
and live thousands of miles apart.
SQLite can survive a continental catastrophe.

<li><p>
<b>Buzz resistant</b> &rarr;
Though noone is completely immune to trends and fads, the SQLite
developers work hard to avoid being sucked into the latest programming
fashion.  Our aim is to produce timeless code that will be
readable, understandable, and maintainable by programmers 
who have not yet been born.
</ul>

<p>
In addition to "supporting" SQLite through the year 2050, the developers
also promise to keep the SQLite 
[cintro|C-language API] and [file format|on-disk format] 
fully backwards compatible.
This means that application written to use SQLite today should be able to
link against and use future versions of SQLite released decades in the
future.