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
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 |