> If fact it is - right buddy - but some {loo|u}sers think
> "BETA" is something ready for use with the risk of having to
> install some bugfixes later. But using our BETA might require
> to dump/reload and that's not simply installing a fix.
>
> It all has to do with how we handle our BETA phase. I know, I
> was myself one of those who caused an initdb during this. It
> was required for one of our TODO's for v6.5.
>
> In the future, at the moment we want to declare current CVS
> beeing BETA, we should identify all those TODO items that
> potentially require an initdb and decide upon them if they
> have to go into the next release or if they cause a BETA
> delay. After we declared BETA, any TODO item that requires an
> initdb must by default go into the next release. Closed shop!
We usually discourage any initdb changes in beta, but we have had so
many required ones, it we didn't make any big deal about it in 6.5.
I belive earlier releases have not required dump/reload in beta. I know
it has happened only a few times in three years. 6.5 did it a lot,
partially because we now understand so much more, and are mucking/fixing
so much more detailed code.
It is clearly more than an alpha, were we expect serious breakage. We
have a list of clearly-defined bugs for the release. Maybe we call it
beta-light. Also, we require beta people to be on the hackers list, so
they can know of dump/reload, so it is sort of a subscriber beta.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026