Re: 9.1 Beta

On Sat, Mar 26, 2011 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)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