Shane Ambler <pgsql@007Marketing.com> writes:
> Bill Moran wrote:
>> Does the PostgreSQL project have any similar policy about EoLs?
> There is no set time frame planned that I know of.
No, there's no agreed-on policy. So far there's really only been one
release that we've actively decided to decommission, and that was 7.2.
Before about 7.1 or 7.2, to be frank, the code base was not solid enough
that anyone would expect long-term support; nor did we have the manpower
to consider back-patching any more than the latest release version.
So it was simply not a consideration before that. We dropped 7.2 when
we decided it was unfixably broken --- I don't recall the specific
motivation anymore, but it was a we-can't-fix-this-without-initdb kind
of problem, and if you're gonna initdb you might as well move to a newer
release branch.
> It is more a matter of users that keep the old versions alive.
Even more to the point, a matter of developers being willing to take
the time to ensure that critical fixes are back-ported to old branches.
Right now I think the driving force here is that Red Hat is paying me
to make critical fixes for versions that are in their supported RHEL
releases, namely PG 7.3 and 7.4. The EOLs for those RHEL versions are
still depressingly far away :-(. The rest of core does not care at all
about 7.x, but they're willing to humor me to the extent of wrapping
tarballs as long as I keep putting the bug fixes into CVS.
There's been some idle discussion on the lists about establishing an
official project policy, perhaps "five years from release", but I don't
see that as meaning anything, because in the end this is still all
driven by developers scratching their own itch (or their company's itch).
Way-back releases are going to get supported for exactly as long as
someone's willing to do the work. And future occurrences of the 7.2
"this is unfixable" decision are certainly not impossible, and would
throw a monkey wrench into any such plan anyway.
regards, tom lane