On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote: > 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.
I can see being cautious. I'm just questioning the value of this precaution in particular. > 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. We've bumped catversion in beta and even RC, if I recall right. > And I doubt we'd bother generating pg_migrator builds that work for > pairs of alpha releases. That's an interesting idea. Shouldn't pg_migrator be mandated to work for *any* catversion bump? Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
