PostgreSQL Release Support Policy
After a great deal of discussion in the community, the project's core
team have written a policy outlining the support lifecycle for major
PostgreSQL releases, which can be found on the wiki with other project
policies at http://wiki.postgresql.org/wiki/Policies.
We hope this document will help our users plan their deployments more
effectively.
--------
The PostgreSQL project aims to fully support a major release for five years.
After a release falls out of full support, we may (at our committer's
discretion) continue to apply further critical fixes to the source
code, on a best-effort basis. No formal releases or binary packages
will be produced by the project, but the updated source code will be
available from our source code control system.
This policy will be followed on a best-effort basis. In extreme cases
it may not be possible to support a release for the planned lifetime;
for example if a serious bug is found that cannot be resolved in a
given major version without significant risk to the stability of the
code or loss of application compatibility. In such cases, early
retirement of a major version may be required.
End Of Life (EOL) dates:
Version EOL Date
PostgreSQL 7.4 July 2010 (extended)
PostgreSQL 8.0 July 2010 (extended)
PostgreSQL 8.1 November 2010
PostgreSQL 8.2 December 2011
PostgreSQL 8.3 February 2013
PostgreSQL 8.4 July 2014
--------
--
Dave Page
PostgreSQL Core Team
Hi,
On Friday 04 December 2009 17:36:00 Dave Page wrote:
Version EOL Date
PostgreSQL 7.4 July 2010 (extended)
PostgreSQL 8.0 July 2010 (extended)
PostgreSQL 8.1 November 2010
PostgreSQL 8.2 December 2011
PostgreSQL 8.3 February 2013
PostgreSQL 8.4 July 2014
What about adding the shortened windows EOLs there?
Andres
On Fri, Dec 4, 2009 at 5:27 PM, Andres Freund <andres@anarazel.de> wrote:
Hi,
On Friday 04 December 2009 17:36:00 Dave Page wrote:
Version EOL Date
PostgreSQL 7.4 July 2010 (extended)
PostgreSQL 8.0 July 2010 (extended)
PostgreSQL 8.1 November 2010
PostgreSQL 8.2 December 2011
PostgreSQL 8.3 February 2013
PostgreSQL 8.4 July 2014What about adding the shortened windows EOLs there?
Sorry - meant to reply to this earlier. I added a footnote about the
windows support for <= 8.1
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
On Fri, 2009-12-04 at 16:36 +0000, Dave Page wrote:
End Of Life (EOL) dates:
Version EOL Date
PostgreSQL 7.4 July 2010 (extended)
PostgreSQL 8.0 July 2010 (extended)
PostgreSQL 8.1 November 2010
PostgreSQL 8.2 December 2011
PostgreSQL 8.3 February 2013
PostgreSQL 8.4 July 2014
Could I request we change these dates slightly to
PostgreSQL 8.1 February 2011
PostgreSQL 8.2 February 2012
with absolutely no intention to extend the support window any worthwhile amount.
That way we have
* A regular pattern of de-release, so everybody is clearer, i.e.
PostgreSQL 8.1 February 2011
PostgreSQL 8.2 February 2012
PostgreSQL 8.3 February 2013
* We don't have de-support right at Thanksgiving or Christmas, since
people may do panic-stricken upgrades.
I much prefer February as a time for panic, if that choice is available,
which I realise it may not be.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs <simon@2ndQuadrant.com> writes:
Could I request we change these dates slightly to
The intent of the policy is that the last formal minor release for a
branch will happen no earlier than the specified times. It might well
be later, since we're not going to schedule updates specially for this
--- it'd be whenever the next set of updates occur, and that would more
likely be driven by bugs in newer branches, not the oldest one.In any case there's no need for someone to move off a version instantly
the day after the last release for it. So I really don't see why you
think there would be "panic updates". There's so much fuzz in when a
version would be effectively dead that a few months either way in the
nominal date wouldn't make any difference anyway.
regards, tom lane
On Sat, 2009-12-05 at 15:33 -0500, Tom Lane wrote:
In any case there's no need for someone to move off a version instantly
the day after the last release for it. So I really don't see why you
think there would be "panic updates".
Hmm, well, I wasn't imagining it as a wholly rational response. I guess
the existence of such a panic remains to be proven amongst our users,
who I should give more credit to than their counterparts that still use
other products.
--
Simon Riggs www.2ndQuadrant.com