Re: 9.1 Beta

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?

regards, tom lane