On Sat, Mar 26, 2011 at 3:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
