On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, that would be overstating my position. We haven't stopped
> supporting it, but there's less and less stuff that applies that far
> back. I think it's better to draw a line in the sand and say "we're
> going to stop supporting this release on this date" rather than
> letting it go on and on and then waking up and realizing "hmm, nothing
> ever applies that far back any more, I guess we don't support it".
If there are few or no patches that have to be back-patched then that
seems like an argument against EOLing it -- we can support it
basically for free!
Realistically we're going to EOL it as soon as the first major bug is
found that *doesn't* back patch readily. There's relatively low cost
to supporting it up until that bug is found, and apparently it hasn't
been found it.
The dangers I see are:
1) The committers waste time back patching minor bug fixes to a
release we would rather people not be using anyways.
2) Relatively few people are using it so perhaps the reason we haven't
found any major bugs recently is because nobody's pushing it hard any
more.
3) We're effectively making a promise we have no intention of
delivering on. We claim we "support" it but when we find that
hard-to-fix security problem or data corruption problem we'll suddenly
EOL it leave people hanging.
I think all of these are pretty minor problems in practice. The first
because the committers themselves don't seem to be concerned, the
second because these releases got pushed pretty hard for pretty long
already, and the third because as Steve Crawford mentioned EOLing
software doesn't instantly render it useless. It's not like we make
any real support commitments unless you actually contract one of our
employers anyways. And even if a bug isn't fixed you can usually
engineer your application to work around the problem anyways by, for
example, avoiding use of hash indexes or using password authentication
instead of SSL certs, or whatever.
--
greg