Alpha releases: How to tag

* Peter Eisentraut (peter_e@gmx.net) wrote:

- branch
- apply version number change to source tree
- commit
- tag

If this wasn't CVS, this would certainly be the way to go.

or alternatively no tag at all, just apply version number and build tarball.

As this *is* CVS, I'm thinking we should probably go with this approach.

Just my 2c.

Thanks,

Stephen

Peter Eisentraut wrote:

As we are approaching the first alpha release, let's think about how to tag
and label it and how to schedule those two operations with respect to one
another.

The typical process for, say, a beta release is

- apply version number change to source tree
- commit
- tag
(repeat for next beta)

The problem, arguably, with this is that the source tree would then read
8.5alpha1 until alpha2, instead of the 8.5devel that we are used to. The fix
could be:

- apply version number change to source tree
- commit
- tag
- revert version number change in source tree
- commit
(repeat for next alpha)

or more sophisticatedly

- branch
- apply version number change to source tree
- commit
- tag

or alternatively no tag at all, just apply version number and build tarball.

Comments?

Does it need a version number change? Maybe just a tag (no branch) is
all that is required.

cheers

andrew

On Aug 3, 2009, at 7:57 AM, Stephen Frost <sfrost@snowman.net> wrote:

* Peter Eisentraut (peter_e@gmx.net) wrote:

- branch
- apply version number change to source tree
- commit
- tag

If this wasn't CVS, this would certainly be the way to go.

or alternatively no tag at all, just apply version number and build
tarball.

As this *is* CVS, I'm thinking we should probably go with this
approach.

Sounds right to me.

...Robert

Andrew Dunstan <andrew@dunslane.net> writes:

Does it need a version number change? Maybe just a tag (no branch) is
all that is required.

I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha release
corresponds to. Peter's label-and-undo approach seems like a kluge;
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.

I feel that making a branch is the way to go. If we try to get away
with a shortcut, we'll probably regret it.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Does it need a version number change? Maybe just a tag (no branch) is
all that is required.

I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha release
corresponds to. Peter's label-and-undo approach seems like a kluge;
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.

I feel that making a branch is the way to go. If we try to get away
with a shortcut, we'll probably regret it.

Yes, if that's what we want then definitely branch. I guess the branch
will (almost) only ever have exactly one commit on it.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

... it doesn't scale to consider the possibility that we might
want to re-release an alpha after fixing some particularly evil bug.

Yes, if that's what we want then definitely branch. I guess the branch
will (almost) only ever have exactly one commit on it.

Yeah, I'd expect so; but it seems like a good idea to leave room for the
possibility of more than one commit. I was first thinking that we'd
just release a new alpha from CVS HEAD if the evil-bug situation comes
up. However, if we've already done a catversion bump or some other
incompatible change in HEAD, that wouldn't be very practical.

regards, tom lane

On Monday 03 August 2009 17:44:32 Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Does it need a version number change? Maybe just a tag (no branch) is
all that is required.

I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha release
corresponds to. Peter's label-and-undo approach seems like a kluge;
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.

I feel that making a branch is the way to go. If we try to get away
with a shortcut, we'll probably regret it.

Another more lightweight alternative is to tag and then change the version
number and build the tarball, without another commit. This assumes that the
version number stamping is automated and reproducible, so you don't have to
record it in history.

On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Does it need a version number change? Maybe just a tag (no branch)
is all that is required.

I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha
release corresponds to. Peter's label-and-undo approach seems like
a kluge;

Right.

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.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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.

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

Peter Eisentraut <peter_e@gmx.net> writes:

On Monday 03 August 2009 17:44:32 Tom Lane wrote:

I feel that making a branch is the way to go. If we try to get away
with a shortcut, we'll probably regret it.

Another more lightweight alternative is to tag and then change the version
number and build the tarball, without another commit. This assumes that the
version number stamping is automated and reproducible, so you don't have to
record it in history.

The stamping is reproducible enough, I think, but don't we have the
tarball build process set up so that it pulls the tarball directly
from a particular CVS tag?

Anyway, the reason I'm for a branch is not that. It's so we have the
option to issue an 8.5alpha1.1 update if we need to.

regards, tom lane

On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane 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.

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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david@fetter.org> writes:

On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:

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?

Oh, are you volunteering to make that happen? That code is going to be
ugly enough just dealing with pairs of major releases ...

regards, tom lane

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 Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

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?

To my mind there are three categories of stuff that pg_migrator has to
do:

* catalog changes (handled by pg_dump/reload)
* on-disk data layout changes (not handled yet anyway)
* random weird unclassifiable stuff

It's the third category that is the problem. An example from the 8.3 to
8.4 migration is the need to specially handle sequences because they're
not compatible on-disk. Any pair of releases you might pick is going to
have its own little quirks like that. Our intention (at least as I see
it) is to minimize pg_migrator's complexity by decreeing that any given
release of pg_migrator deals with exactly one pair of PG releases.
I don't think that works if alpha->alpha has to be supported --- in
particular, 8.5alpha1 to 8.5alpha2 might be quite different from what
will be needed later for 8.4 to 8.5, so you would end up with multiple
live branches of pg_migrator, or else a lot of spaghetti code trying to
track which actions to take for a given case.

The other little problem is who's going to do this work and when.
The alpha-release idea was sold to us on the basis of being a small
amount of incremental work: just tag an alpha release right after
CommitFest and kick it out there. If we're waiting around for someone
to produce and test a compatible pg_migrator, that's not going to be
how it works.

regards, tom lane

On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:

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?

Oh, are you volunteering to make that happen? That code is going to
be ugly enough just dealing with pairs of major releases ...

With all due respect, if pg_migrator does not function in such a way
as to have data-driven composable changes, it's going to bang us up in
the long haul much worse than not branching alphas ever could.

We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog changes which do not
include need migration changes. That's how it works in every other
RDBMS outfit that has changes on disk, and we do not need to be the
exception.

If pg_migrator doesn't have this ability, we need to refactor it until
it does, or go with something that can.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Monday 03 August 2009 21:07:00 David Fetter wrote:

We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog changes which do not
include need migration changes. That's how it works in every other
RDBMS outfit that has changes on disk, and we do not need to be the
exception.

Well, blocker number one for that is that pg_migrator is not even in the
PostgreSQL CVS repository, but is more like an endorsed third-party product.

On Mon, Aug 3, 2009 at 2:07 PM, David Fetter<david@fetter.org> wrote:

On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:

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?

Oh, are you volunteering to make that happen?  That code is going to
be ugly enough just dealing with pairs of major releases ...

With all due respect, if pg_migrator does not function in such a way
as to have data-driven composable changes, it's going to bang us up in
the long haul much worse than not branching alphas ever could.

We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog changes which do not
include need migration changes.  That's how it works in every other
RDBMS outfit that has changes on disk, and we do not need to be the
exception.

If pg_migrator doesn't have this ability, we need to refactor it until
it does, or go with something that can.

I don't disagree with this, but we don't have anyone to do the work
atm, even if it were exactly clear what to do, which it isn't. What
we could do, though, is try to figure out whether it will work between
8.4.0 and 8.5alpha1.

...Robert

On Mon, Aug 03, 2009 at 09:22:52PM +0300, Peter Eisentraut wrote:

On Monday 03 August 2009 21:07:00 David Fetter wrote:

We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog changes which do
not include need migration changes. That's how it works in every
other RDBMS outfit that has changes on disk, and we do not need to
be the exception.

Well, blocker number one for that is that pg_migrator is not even in
the PostgreSQL CVS repository, but is more like an endorsed
third-party product.

I'm not entirely sure that pg_migrator should be tied to releases of
PostgreSQL, given what it does. Or did you mean that it's not been
given the same scrutiny that the PostgreSQL code base has?

Thoughts?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Monday 03 August 2009 22:52:55 David Fetter wrote:

On Mon, Aug 03, 2009 at 09:22:52PM +0300, Peter Eisentraut wrote:

On Monday 03 August 2009 21:07:00 David Fetter wrote:

We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog changes which do
not include need migration changes. That's how it works in every
other RDBMS outfit that has changes on disk, and we do not need to
be the exception.

Well, blocker number one for that is that pg_migrator is not even in
the PostgreSQL CVS repository, but is more like an endorsed
third-party product.

I'm not entirely sure that pg_migrator should be tied to releases of
PostgreSQL, given what it does. Or did you mean that it's not been
given the same scrutiny that the PostgreSQL code base has?

Well, how to you expect to mandate that all patches come with upgrade support
if the PostgreSQL software proper does not contain any upgrade support in the
first place, because pg_migrator is maintained elsewhere.