On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane <g...@turnstep.com> wrote: >> 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. > > I hope this is not the case, for sane definitions of "readily". We have > an implicit promise to support 7.4 until we state that we've stopped > doing so. Stopping because a patch is hard seems a real crappy excuse. > For the record, I'd like to see a year's notice. How about Dec. 1, 2010? > February is completely not reasonable. Companies need a lot more time to > make plans, get approval, test, etc.
It seems like a fine excuse to me. I certainly don't feel i have any authority to tell Tom or Alvarro what to work on in their spare time. If you feel the urge to do it if Tom thinks it's too much work to be worthwhile then, well, more power to you, thanks. These companies are free to keep using the software with the known problems or pay someone to support it and do the pointless work fixing bugs in five-year-old versions if they want. It looks to me like our "support policy" and past success at back patching has engendered a false sense of security for users. *All* our support is "best-effort" and what I described is effectively our policy for all back branches. The only question is which branches, in our best judgement, we think we're likely to run into such a problem. It's not likely for 8.3 currently because we know there aren't very many major changes in 8.4 that fixed potential major design bugs. It's certainly likely for 7.4 at this point and really 8.0 and 8.1 wouldn't surprise me either. That doesn't mean we have to stop back patching to 7.4, 8.0, and 8.1 today. But if we think it's likely we'll run into some major bug which requires a redesign to fix then we should perhaps make some statement to that effect, call these back branches EOL today, and just release back branches on a best effort basis until that occurs. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers