Thread: 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 ---------------------------(end of broadcast)--------------------------- -To unsubscribe from this list, send an email to: pgsql-announce-unsubscribe@postgresql.org
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 2014 > What 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