Re: Release planning (was: Re: Status report) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Release planning (was: Re: Status report)
Date
Msg-id 19845.1089759236@sss.pgh.pa.us
Whole thread Raw
In response to Re: Release planning (was: Re: Status report)  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: Release planning (was: Re: Status report)  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> But Tom's assertion is true.  We have enough trouble getting patches 
>> rolled out; adding parallel branches is just begging for trouble, due to 
>> our relatively small resource size.  Although, we probably have enough 
>> developers at this point to make it happen.

> Except, we already have parallel branches, else we'd never have made a 
> 7.4.x release ...

The point though is that we expend only very minimal effort on
maintaining the stable branches.  We only back-patch bug fixes, and 99%
of the time the patch is nearly verbatim the same change as we developed
to fix the same problem in HEAD.  If the code involved has changed
enough that a significantly different fix would be required, most of the
time we simply don't fix the stable branch.  And we spend very nearly
zero effort on QA for the stable branch --- there's certainly no
significant push to get people to beta-test minor releases.

If we did anything much in the way of back-porting features then the
level of investment in this would have to rise greatly.  In fact, if the
proposal is to let people pick and choose which back-ported things they
install, then we are not talking about just one stable version but 2^N
stable versions for N options.  We couldn't possibly test every
combination.

>> The BSD's release something like that, with CURRENT, TESTING, and STABLE,
>> right? (I'm not a big BSD user...)

Yeah, but they don't support mix-and-match feature sets.  A back release
has only one current version.

We could certainly do something along that line if we had a few people
willing to be "gatekeepers".  We'd have to work harder at making the
release generation process open and documented though.  Right now there
are plenty of steps that only you, Bruce, or Lamar (respectively) know
how to do...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Point in Time Recovery
Next
From: Peter Eisentraut
Date:
Subject: Re: Proposal for detecting encoding mismatch in initdb