On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>>> Any ideas?
>
>> The lower bound on the release cycle is about 12 months right now
>> because we intend to support old versions for 5 years, and 5 or 6
>> branches at once is about the most anyone can handle. That formula is
>> tough to change.
>
> Another problem is that it's very debatable whether users (as opposed
> to developers) want a fast release cycle. Some of that reluctance to
> update might dissipate if we had a better upgrade-in-place story, but
> by no means all of it. People don't want to have to retest their
> applications every six months.
I didn't mean to imply that we should try to release every 6 months,
if that's what it sounded like. I think annual release cycles are
fine. I don't like the idea of letting it slip to 15 or 18 months,
though.
> I agree with trying to cut down the submission-to-commit delay, but
> the release cycle length is not primarily determined by what patch
> authors would like ...
It seems to me that the CommitFest process is pretty darn effective at
reducing the submission-to-commit delay, except when you miss the last
one for the release - then it sucks hard.
I prefer annual release cycles as a user, not just as a developer. If
I start a new project now, it'll be based on 8.4.2. If 8.4 had never
happened and 8.3 were still the current release, any new project I
started would have to be based on 8.3. Of course, I still have
several systems running 8.3 (and I think even 8.2) that are chugging
along just fine; they lose nothing from 8.4 having been released.
...Robert
