{%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%}