On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
