David Fetter <da...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
