Greg Stark <gsst...@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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
