Joshua D. Drake <j...@commandprompt.com> wrote: > On 06/06/2015 07:14 PM, Peter Geoghegan wrote: >> On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> Perhaps we're honoring this more in the breech than in the >>> observance, but I'm not making up what Tom has said about this: >>> >>> http://www.postgresql.org/message-id/27310.1251410...@sss.pgh.pa.us That's 9.0 release discussion: | I think that the traditional criterion is that we don't release beta1 | as long as there are any known issues that might force an initdb. | We were successful in avoiding a post-beta initdb this time, although | IIRC the majority of release cycles have had one --- so maybe you | could argue that that's not so important. It would certainly be | less important if we had working pg_migrator functionality to ease | the pain of going from beta to final. >>> http://www.postgresql.org/message-id/19174.1299782...@sss.pgh.pa.us That's 9.1 release discussion: | Historically we've declared it beta once we think we are done with | initdb-forcing problems. | In any case, the existence of pg_upgrade means that "might we need | another initdb?" is not as strong a consideration as it once was, so | I'm not sure if we should still use that as a criterion. I don't know | quite what "ready for beta" should mean otherwise, though. >>> http://www.postgresql.org/message-id/3413.1301154...@sss.pgh.pa.us Also 9.1, it is listed as one criterion: | * 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) >>> http://www.postgresql.org/message-id/3261.1401915...@sss.pgh.pa.us Here we jump to 9.4 discussion: | > Agreed. Additionally I also agree with Stefan that the price of a initdb | > during beta isn't that high these days. | | Yeah, if nothing else it gives testers another opportunity to exercise | pg_upgrade ;-). The policy about post-beta1 initdb is "avoid if | practical", not "avoid at all costs". So I think these examples show that the policy has shifted from a pretty strong requirement to "it's probably nice if" status, with some benefits seen in pg_upgrade testing to actually having a bump. >> Of course, not doing a catversion bump after beta1 doesn't necessarily >> have much value in and of itself. *Promising* to not do a catversion >> bump, and then usually keeping that promise definitely has a certain >> value, but clearly we are incapable of that. As someone who was able to bring up a new production application on 8.2 because it was all redundant data and not yet mission-critical, I appreciate that in very rate circumstances that combination could have benefit. But really, how often are people in that position? > It seems to me that a cat bump during Alpha or Beta should be absolutely > fine and reservedly fine respectively. Where we should absolutely not > cat bump unless there is absolutely no other choice is during and RC. +1 on all of that. And for a while now we've been talking about an alpha test release, right? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
