mirror of
https://github.com/postgres/pgweb.git
synced 2025-08-03 15:38:59 +00:00

While the permanent redirect will fix this over the course of time, it is still better that we do not reference the old path from pgweb.
104 lines
3.5 KiB
HTML
104 lines
3.5 KiB
HTML
{%extends "base/page.html"%}
|
|
{%block title%}Versioning Policy{%endblock%}
|
|
{%block contents%}
|
|
|
|
<h1>Versioning Policy <i class="fas fa-code-branch"></i></h1>
|
|
|
|
<p>
|
|
The PostgreSQL Global Development Group releases a new major version containing
|
|
new features about once a year. Each major version receives bug fixes and, if
|
|
need be, <a href="/support/security/">security</a> fixes that are released at
|
|
least once every three months in what we call a "minor release." For more
|
|
information on the minor release schedule, you can view the
|
|
<a href="/developer/roadmap/">minor release roadmap</a>.
|
|
<p>
|
|
|
|
<p>
|
|
If the release team determines that a critical bug or security fix is too
|
|
important to wait until the regularly scheduled minor release, it may make
|
|
a release available outside of the minor release roadmap.
|
|
</p>
|
|
|
|
<p>
|
|
The PostgreSQL Global Development Group supports a major version for 5 years
|
|
after its initial release. After its five year anniversary, a major version will
|
|
have one last minor release containing any fixes and will be considered
|
|
end-of-life (EOL) and no longer supported.
|
|
</p>
|
|
|
|
<h2>Version Numbering</h2>
|
|
|
|
<p>
|
|
Starting with PostgreSQL 10, a major version is indicated by increasing the
|
|
first part of the version, e.g. 10 to 11. Before PostgreSQL 10, a major version
|
|
was indicated by increasing either the first or second part of the version
|
|
number, e.g. 9.5 to 9.6.
|
|
</p>
|
|
|
|
<p>
|
|
Minor releases are numbered by increasing the last part of the version number.
|
|
Beginning with PostgreSQL 10, this is the second part of the version number,
|
|
e.g. 10.0 to 10.1; for older versions this is the third part of the version
|
|
number, e.g. 9.5.3 to 9.5.4.
|
|
</p>
|
|
|
|
<h2>Upgrading</h2>
|
|
|
|
<p>
|
|
<strong>
|
|
We always recommend that all users run the latest available minor
|
|
release for whatever major version is in use.
|
|
</strong>
|
|
</p>
|
|
|
|
<p>
|
|
Major versions usually change the internal format of system tables and data
|
|
files. These changes are often complex, so we do not maintain backward
|
|
compatibility of all stored data. A dump/reload of the database or use of the
|
|
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
|
|
for major upgrades. We also recommend reading the
|
|
<a href="/docs/current/upgrading.html">upgrading</a> section of the major
|
|
version you are planning to upgrade to.
|
|
</p>
|
|
|
|
<p>
|
|
Upgrading to a minor release does not normally require a dump and restore; you
|
|
can stop the database server, install the updated binaries, and restart the
|
|
server. For some releases, manual changes may be required to complete the
|
|
upgrade, so always read the release notes before upgrading.
|
|
</p>
|
|
|
|
<p>
|
|
While upgrading will always contain some level of risk, PostgreSQL minor releases
|
|
fix only frequently-encountered bugs, <a href="/support/security/">security</a>
|
|
issues, and data corruption problems to reduce the risk associated with
|
|
upgrading. For minor releases, <em>the community considers not upgrading to be
|
|
riskier than upgrading.</em>
|
|
</p>
|
|
|
|
<h2>Releases</h2>
|
|
|
|
<table class="table table-striped">
|
|
<thead class="thead-light">
|
|
<tr>
|
|
<th>Version</th>
|
|
<th>Current minor</th>
|
|
<th>Supported</th>
|
|
<th>First Release</th>
|
|
<th>Final Release</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
{%for v in versions%}
|
|
<tr>
|
|
<td>{{v.numtree}}</td>
|
|
<td>{{v.numtree}}.{{v.latestminor}}</td>
|
|
<td>{{v.supported|yesno:"Yes,No"}}</td>
|
|
<td>{{v.firstreldate|date:"F j, Y"}}</td>
|
|
<td>{{v.eoldate|date:"F j, Y"}}</td>
|
|
</tr>
|
|
{%endfor%}
|
|
</tbody>
|
|
</table>
|
|
{%endblock%}
|