Documentation Source Text

<p>The ALWAYS(X) and NEVER(X) macros are a weaker statement about the
truth of X.  The presence of ALWAYS(X) or NEVER(X) means that the developers
believe X is always or never true, but there is no proof, or the proof
is complex and error-prone, or the proof depends on other aspects 
of the system that seem likely to change.

<p>In other systems sometimes use assert(X) in a way that is
similar to the use of ALWAYS(X) or NEVER(X) in SQLite.
Developers will add an assert(X) as a 
[https://blog.regehr.org/archives/1576|tacit acknowledgement that they
do not fully believe that X is always true].
We believe that this use of assert(X) is wrong and violates the intent
and purpose of having assert(X) available in C in the first place.
An assert(X) should not be seen as a safety-net or top-rope used to

<p>The ALWAYS(X) and NEVER(X) macros are a weaker statement about the
truth of X.  The presence of ALWAYS(X) or NEVER(X) means that the developers
believe X is always or never true, but there is no proof, or the proof
is complex and error-prone, or the proof depends on other aspects 
of the system that seem likely to change.

<p>Other systems sometimes use assert(X) in a way that is
similar to the use of ALWAYS(X) or NEVER(X) in SQLite.
Developers will add an assert(X) as a 
[https://blog.regehr.org/archives/1576|tacit acknowledgement that they
do not fully believe that X is always true].
We believe that this use of assert(X) is wrong and violates the intent
and purpose of having assert(X) available in C in the first place.
An assert(X) should not be seen as a safety-net or top-rope used to

<title>SQLite Developers</title>
<tcl>hd_keywords {crew} {Hipp} {Kennedy}</tcl>

<fancy_format>

<h2>The SQLite Development Team</h2>

<img src="images/drh1.jpg" align="left" hspace="25" vspace="0">
<p>
<b>D. Richard Hipp
</b> began the SQLite project on 2000-05-29
and continues to serve as the project architect.  Richard was born,
lives, and works in 
[http://en.wikipedia.org/wiki/Charlotte,_North_Carolina | Charlotte, North Carolina.]  He holds degrees from

<title>SQLite Developers</title>
<tcl>hd_keywords {crew} {Hipp} {Kennedy}</tcl>

<fancy_format>



<img src="images/drh1.jpg" align="left" hspace="25" vspace="0">
<p>
<b>D. Richard Hipp
</b> began the SQLite project on 2000-05-29
and continues to serve as the project architect.  Richard was born,
lives, and works in 
[http://en.wikipedia.org/wiki/Charlotte,_North_Carolina | Charlotte, North Carolina.]  He holds degrees from

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.

<p>
Our goal is to make the content you store in SQLite today as 
easily accessible to your grandchildren as it is to you.

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.

<p>
Our goal is to make the content you store in SQLite today as 
easily accessible to your grandchildren as it is to you.

<p>
<b>Update on 2018-05-39:</b>
Our goal of supporting SQLite long-term have apparently come to the
notice of the preservations at the 
[https://www.loc.gov|US Library Of Congress] who have identified
SQLite as a [recommended storage format] for the preservation of
digital content.

compatible. 
</p>

<p>
The stability of the SQLite database file format and the fact
that the file format is cross-platform combine to make SQLite
database files an excellent choice as an 
[Application File Format].</p>




</p>

<hr>
<div style='font-size: 75%;'>
<p>Notes:
<ol>
<li>Temporary journal files are created as part of transaction control,
but those extra files are not part of the steady-state database.
</ol>
</div>

compatible. 
</p>

<p>
The stability of the SQLite database file format and the fact
that the file format is cross-platform combine to make SQLite
database files an excellent choice as an 
[Application File Format].
The US Library Of Congress acknowledges this by listing SQLite
as a [recommended storage format] for long-term preservation of
digital content.
</p>
</p>

<hr>
<div style='font-size: 75%;'>
<p>Notes:
<ol>
<li>Temporary journal files are created as part of transaction control,
but those extra files are not part of the steady-state database.
</ol>
</div>

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

<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