mirror of
https://github.com/postgres/pgweb.git
synced 2025-08-12 23:05:12 +00:00
11988adfc2
The updates don't change the policy, but rather add clarifications around it given an influx of questions around how the policy works. Author: Bruce Momjian <bruce@momjian.us>
105 lines
3.4 KiB
HTML
105 lines
3.4 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 this, a final minor version will be released
|
|
and the software will then be unsupported (end-of-life).
|
|
</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>
|
|
Major versions make complex changes, so the contents of the data directory
|
|
cannot be maintained in a backward compatible way. A dump/reload of the
|
|
database or use of the
|
|
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> application 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. You can upgrade from one major version
|
|
to another without upgrading to intervening versions, but we recommend reading
|
|
the <a href="/docs/release/">release notes</a> of all intervening major
|
|
versions prior to doing so.
|
|
</p>
|
|
|
|
<p>
|
|
Minor release upgrades do not require a dump and restore; you simply stop
|
|
the database server, install the updated binaries, and restart the server.
|
|
Such upgrades might require additional steps so always read
|
|
the release notes first.
|
|
</p>
|
|
|
|
<p>
|
|
Minor releases only contain fixes for frequently-encountered bugs,
|
|
low-risk fixes, <a href="/support/security/">security</a> issues, and
|
|
data corruption problems. <em>The community considers performing minor
|
|
upgrades to be less risky than continuing to run an old minor version.</em>
|
|
</p>
|
|
|
|
<p>
|
|
<strong>
|
|
We recommend that users always run the current minor release associated
|
|
with their major version.
|
|
</strong>
|
|
</p>
|
|
|
|
<h2>Releases</h2>
|
|
|
|
<table class="table table-striped">
|
|
<thead>
|
|
<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%}
|