Re: Beta2 on Friday Morning (Was: Re: Open 7.3 items)

I have to say that during beta testing I ALWAYS do an initdb and a reload 
just to make sure the pg_dumpall and pg_restore stuff works right.  Plus 
to make sure problems that might only pop up with a new initdb are found 
as well.  I probably "burn it to the ground" several times on a single 
beta just to test different data sets and I prefer a clean database when 
doing that so I'm sure the problems I see are from just that one dataset.

So, Requiring an initdb for every beta wouldn't bother me one bit.  To me 
you test a beta by migrating to it just like it was a production version, 
and that means a new build from the ground up, initdb and all.

On 18 Sep 2002, Neil Conway wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > On Wed, 18 Sep 2002, Bruce Momjian wrote:
> > > We should get _all_ the known initdb-related issues into the code
> > > before we go beta2 or beta3 is going to require another initdb.
> > 
> > Right, and?  How many times in the past has it been the last beta in
> > the cycle that forced the initdb?  Are you able to guarantee that
> > there won't* be another initdb required if we wait until mid-next
> > week?
> 
> I completely agree with Bruce here. Requiring an initdb for every beta
> release significantly reduces the number of people who will be willing
> to try it out -- so initdb's between betas are not disasterous, but
> should be avoided if possible.
> 
> Since waiting till next week significantly reduces the chance of an
> initdb for beta3 and has no serious disadvantage that I can see, it
> seems the right decision to me.
> 
> Cheers,
> 
> Neil
> 
>