By chance I happened to notice in the release notes Release 7.3 Release date: 2002-11-27 Man, it feels like a long time since that came out... There has been some discussion of making a project policy of dropping support for old releases after five years. Should we consider formally instituting that? I see that there are two or three minor bug fixes in the REL7_3_STABLE branch since 7.3.20. Rather than just leaving those to rot, maybe the actual policy should be "only one more update after 8.3 comes out". Comments, opinions? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Dave Page" <dpage@postgresql.org> writes: >> From: Tom Lane <tgl@sss.pgh.pa.us> >> I see that there are two or three minor bug fixes in the REL7_3_STABLE >> branch since 7.3.20. Rather than just leaving those to rot, maybe the >> actual policy should be "only one more update after 8.3 comes out". > I assume you no longer need to maintain it for Redhat then? Well, I still do, nominally, but RHEL-3 is in maintenance mode (meaning no more scheduled updates). It would take a fairly serious bug to get Red Hat's attention to the point that they'd want to turn the package. If something like that came up, very possibly we'd want to put out a fix too. What I'm thinking is more along the lines of not bothering with back-patching non-catastrophic bugs, and not automatically including 7.3 in the set of branches we make back-branch releases for. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Josh Berkus <josh@agliodbs.com> writes: >> There has been some discussion of making a project policy of dropping >> support for old releases after five years. Should we consider formally >> instituting that? > The community consensus I recall was three versions only. Anything beyond > that would be up to the vendors. Yeah, but some of us are also the vendors ;-). I still figure that if I have to maintain branch X for Red Hat, I might as well put those fixes in the community CVS. I should think that Sun, EDB, et al would also find it expedient to not need to maintain private patch sets. So it seems to me that the "vendor" EOL horizons are legitimate to consider while deciding what the "community" wants to support. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

"Andreas 'ads' Scherbaum" <adsmail@wars-nicht.de> writes: > On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote: >> Release 7.3.21 with and EOL addendum :). E.g; this is the last release >> of 7.3 and 7.3 is now considered unsupported. > I know at least one customer who is using RHEL-3 and PG 7.3 on dozens > machines worldwide. Are they running 7.3.20? Will they update to 7.3.21 promptly when we ship it? Or are they using whatever Red Hat includes in RHEL-3? (which is still 7.3.19 I believe) One of the reasons for losing interest in frequent updates is that it seems most of the people we hear from who are running 7.3.x are running a pretty obsolete "x". If we produce an update and no one actually installs it, we're just wasting time with make-work. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Gregory Stark <stark@enterprisedb.com> writes: > Whether there's any need to support the old protocol in the server depends on > whether there are any clients out there which use it which is harder to > determine and not affected by whether Postgres 7.3 is still around. Right. There's really not much to be gained by dropping it on the server side anyway. libpq might possibly be simplified by a useful amount, but on the other hand we probably want to keep its current structure for the inevitable v4 protocol. Another area where we might think about dropping some stuff is pg_dump. If we got rid of the requirement to support dumps from pre-7.3 servers then it could assume server-side dependencies exist, and lose all the code for trying to behave sanely without 'em. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate