On 2014-05-07 15:00:01 +0200, Magnus Hagander wrote: > On Wed, May 7, 2014 at 2:56 PM, Andres Freund <andres@2ndquadrant.com>wrote: > > > On 2014-05-07 08:50:33 -0400, Robert Haas wrote: > > > On Wed, May 7, 2014 at 7:40 AM, Andres Freund <andres@anarazel.de> > > wrote: > > > > I don't think it's likely that beta1 will be binary compatible with the > > > > final version at this point. > > > > > > I rather think we're not ready for beta1 at this point (but I expect > > > to lose that argument). > > > > Well, I guess it depends on what we define 'beta1' to be. Imo evaluating > > problematic pieces of new code, locating unfinished pieces is part of > > that. I don't see much point in forbidding incompatible changes in beta1 > > personally. That robs th the development cycle of the only period where > > users can actually test the new version in a halfway sane manner and > > report back with things that apparently broken. > > > > > We need to be very careful to tell people about it though. Preferrably if > we *know* a dump/reload will be needed to go beta1->beta2, we should > actually document that in the releasenotes of beta1 already. So people can > make proper plans..
Yes, I think it actually makes sense to add that to *all* beta release notes. Even in beta2, although slightly weakened. That's not a new thing btw. E.g. 9.3 has had a catversion bump between beta1/2: git diff 09bd2acbe5ac866ce9..817a89423f429a6a8b -- src/include/catalog/catversion.h
The more interesting note probably is that there quite possibly won't be pg_upgrade'ability...
Yeah, that's the big thing really.
Requiring pg_upgrade between betas might even be "good" in the sense that then we get more testing of pg_upgrade :) But requiring a dump/reload is going to hurt people more.