From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Thoughts on maintaining 7.3 |
Date: | 2003-10-01 14:44:57 |
Message-ID: | 29101.1065019497@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Tue, 30 Sep 2003, Joshua D. Drake wrote:
>> Of course the theory being that we backport "some" features and fix
>> any bugs that we find?
> Not saying that if someone submit'd patches to v7.3, they wouldn't get
> applied ... only that, to date, the work/effort has been greater then the
> overall benefit, and nobody has step'd up to the plate to do it ...
The idea of backporting features scares me; I really doubt that you can
get enough beta-testing on a back branch to be confident that you
haven't broken anything with a feature addition. In any case you'd be
quite limited in what you could do without forcing an initdb.
Another issue is that people expect dot-releases to be absolutely rock
solid. If you start introducing new features then you considerably
increase the risk of introducing new bugs. (I'm still embarrassed about
7.3.3's failure-to-start bug...)
Our past practice has been to back-port only bug fixes, and only
critical or low-risk ones at that. I think this could be done in a more
thorough fashion, and it could be continued longer than we've done in
the past, but you shouldn't set the scope of the maintenance effort any
wider than that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-10-01 14:49:22 | Re: Thoughts on maintaining 7.3 |
Previous Message | Tom Lane | 2003-10-01 14:31:22 | Re: NOTICE: CREATE TABLE will create implicit triggers for foreign-key checks |