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