Re: Alpha releases: How to tag - Mailing list pgsql-hackers

On Mon, Aug 3, 2009 at 17:32, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> David Fetter <david@fetter.org> writes:
>> On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
>>> and it doesn't scale to consider the possibility that we might want
>>> to re-release an alpha after fixing some particularly evil bug.  A
>>> tag without a branch won't handle that either.
>
>> Is this a use case?  I truly hope nobody will try using a beta, let
>> alone an alpha, in production.  Do we need to provide for such a
>> possibility?  I don't recall that we've ever back-patched a beta, or
>> even a release candidate.
>
> I don't really know if it's a use-case or not; I just have a feeling
> that if we use a release procedure that guarantees we can't do it,
> we'll live to regret that.

Agreed.


> 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?


-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/