On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers