Re: Alpha releases: How to tag

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Alpha releases: How to tag
Date: 2009-08-07 20:04:44
Message-ID: 200908072004.n77K4i810646@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander wrote:
> > The bug-fixing situation for betas and RCs is a bit different because
> > it's expected that there will be a compatible update available shortly.
> > So you can usually assume that updating to the next beta/RC/release will
> > fix whatever problems got found. ?Alphas are going to be out there on
> > their own with absolutely no expectation that the next alpha is
> > catversion-compatible. ?And I doubt we'd bother generating pg_migrator
> > builds that work for pairs of alpha releases.
> >
> > I agree with you that it'd be insane to run anything mission-critical on
> > an alpha build; but I could see someone having loaded up quite a lot of
> > test data on one. ?(If we aren't hoping for some pretty serious testing
> > of these releases, I am not sure what is the point of doing them at all.)
> > So it seems to me that having the ability to fix show-stopper bugs
> > without forcing a migration to a later alpha would be a good thing.
> > Maybe we'll never need it, or maybe we will.
>
> I think the alpha->alpha migration would actually be very useful to
> these testers. That'll get them onto the new alpha. I think that's
> actually a lot more important than alpha->release or release->next
> alpha.
>
> I haven't actually looked into pg_migrator enough to know how likely
> it is that it'll "just work" going alpha->alpha when there have only
> been "normal" changes? How invasive are the changes that actually
> require pg_migrator to be touched at all?

pg_migrator handles 8.5devel just fine now with no changes. What will
happen is that people will try pg_migrator in 8.5devel and if it fails
we will hear about it and and adjust pg_migrator (or the backend) to get
it working. This will give us early warning about backend changes and
hopefully make pg_migrator more useful when 8.5 final is released.

What I have found is that pg_migrator has a useful toolkit for detecting
and correcting database incompatibilities. It wasn't easy to get
working but now that it is complete adding stuff is actually easy ---
see the enum/array/composite fix that was done yesterday within 24 hours
of the report.

Now, I am not guaranteeing that pg_migrator is always going to work for
8.5devel, but while it does let's use it, and when it fails, we can just
update the README to say it doesn't work for 8.5devel, or fix things.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-08-07 20:05:38 Re: Alpha releases: How to tag
Previous Message Bruce Momjian 2009-08-07 20:00:26 Re: Alpha releases: How to tag