On Sat, Mar 26, 2011 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> There's not much point in releasing a beta with behaviour that we know
>> we intend to change. All it will do is elicit bug reports that we have
>> to respond to saying "we know, we were going to change that anyways".
>
>> I think the goal of a beta is to be able to say "we think this is the
>> final behaviour of the next release but we're open to feedback".
>
> Yeah, I think this is a productive way to approach the question.
> I would put on a couple of extra conditions, though. Something like
> this:
>
> * No open issues that are expected to result in user-visible
> behavior changes. (Or at least "significant" changes? But then
> we have to argue about what's significant --- for instance, are
> the questions in the nearby collations-issues thread significant
> enough to be beta blockers?)
>
> * No open issues that are expected to result in a catversion bump.
> (With pg_upgrade, this is not as critical as it used to be, but
> I still think catalog stability is a good indicator of a release's
> maturity)
>
> * No known data-loss-causing bugs (duh)
>
> Comments? Any other quality criteria we should have for beta?
Last 2 are pretty clear.
The first one is debatable because of the word "expected". Who decides that?
I want more feedback into the project. That can obviously result in
changes that are user visible. Users don't complain about non-user
visible things.
I'd state it the other way around: No open issues that are expected to
result in non-user visible architecture changes.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
