Re: Plan for feature freeze?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, jd(at)commandprompt(dot)com, scrappy(at)postgresql(dot)org, andrew(at)dunslane(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Plan for feature freeze?
Date: 2004-05-01 21:28:53
Message-ID: 16383.1083446933@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> However, perhaps *some* of any increase in development time could be
> made up by changing how the beta period is handled.

That would essentially amount to changing our criteria for "start of
beta". How would you like to define it exactly?

We should also think about what exactly we mean by "feature freeze".
I've been using it as a shorthand for "we don't think we'll need any
more major code changes". But depending on how high-level your notion
of "feature" is, it could be that fairly major code changes could still
be acceptable. For instance if "feature" == "Win32 native port" then
all of the work still needed for the Win32 port might be argued to be
acceptable as post-feature-freeze work. (I don't think this is actually
sensible, mind you, since it would be silly to stop other feature
development while Win32 still needs so much work. My point is just that
we haven't defined "feature freeze" very well.)

In the past there has been little if any daylight between feature freeze
and start of beta --- in fact, IIRC we did not distinguish these
concepts at all until the last release or two. It wouldn't be a bad
idea to try to nail down the terms of discussion a bit better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-05-01 21:39:47 Re: Plan for feature freeze?
Previous Message Tom Lane 2004-05-01 21:02:02 Re: Weird prepared stmt behavior