Re: State of support for back PG branches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: State of support for back PG branches
Date
Msg-id 4910.1127774059@sss.pgh.pa.us
Whole thread Raw
In response to Re: State of support for back PG branches  (Devrim GUNDUZ <devrim@gunduz.org>)
Responses Re: State of support for back PG branches
Re: State of support for back PG branches
List pgsql-hackers
Devrim GUNDUZ <devrim@gunduz.org> writes:
> There are some 7.3 users around (I remember some on Slony lists, etc), 
> therefore we should keep supporting it. But maybe we can announce that 
> "7.3 will become unsupported after XXX time" so that people will know 
> before we abandon the support. The best time for not supporting 7.3 might 
> be when 8.2 will be released. However, I believe that 7.4 should live 
> longer, since that's the last of the 7.X branch.

Well, the distinction between the 7.X and 8.X branches is more marketing
than anything else ;-).  I just went back through the release notes and
recalled that 7.2 is the first branch we *ever* continued to support
past the initial release of the next major version --- for all the older
branches, the last point release predates initial release of the next
branch.  And I think we really only started that policy because we found
some pretty serious data-loss bugs shortly after 7.3 came out (see 7.2.4
release notes), and felt we had to do a 7.2 update.

To my mind the main rationale for continuing to support 7.2 is that it
was the last pre-schema release, and so people whose apps haven't yet
been fixed to cope with schemas will be on their own once we drop it.
While each release has some portability gotchas, I don't think there
have been any quite that big since then.  If we drop support for 7.2,
it wouldn't be out of the question for us to drop 7.3 and 7.4 too (at
least not from where I sit ... I'm sure some will differ).

If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like "X amount of time after the release of the
following major version".  But X probably has to depend on how big
the compatibility gotchas are in the following version, so we're still
really talking about a judgment call here.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Database file compatability
Next
From: "Qingqing Zhou"
Date:
Subject: Re: Database file compatability