On Monday 03 August 2009 17:44:32 Tom Lane wrote:
Andrew Dunstan and...@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
daveg da...@sonic.net wrote:
When I was at Sybase, changes to the on disk structure were required
to provide code to do the migration. Nonetheless, at release time,
the migrate process was almost always discovered to be broken,
sometimes even before it was shipped to customers.
As a
On Saturday 08 August 2009 01:28:34 Tom Lane wrote:
David Fetter da...@fetter.org writes:
I am not suggesting that this change be immediate, and it's not ivory
tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
about the
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think it's a lot more nebulous than that. At the same time I think the
days when we can blithely change the on-disk format with hardly a
thought for migration are over. IOW, there's agreement things have to
change, but the
On Aug 7, 2009, at 11:50 PM, Bruce Momjian br...@momjian.us wrote:
David Fetter wrote:
Odds are that the patch submitters will not understand enough to
know how to modify pg_migrator, but just knowing something broke is
usually enough for the hackers group to find a fix.
This is a pretty
Robert Haas wrote:
On Aug 7, 2009, at 11:50 PM, Bruce Momjian br...@momjian.us wrote:
David Fetter wrote:
Odds are that the patch submitters will not understand enough to
know how to modify pg_migrator, but just knowing something broke is
usually enough for the hackers group to find a
On Fri, Aug 07, 2009 at 06:28:34PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
I am not suggesting that this change be immediate, and it's not ivory
tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
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
On Fri, Aug 7, 2009 at 11:35 AM, Bruce Momjianbr...@momjian.us wrote:
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
Robert Haas wrote:
On Mon, Aug 3, 2009 at 2:07 PM, David Fetterda...@fetter.org wrote:
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@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
Alvaro Herrera wrote:
David Fetter wrote:
Is it strictly necessary that its release cycles match exactly those
of the database engine, or would it be OK for it to release as needed,
not triggering a major PostgreSQL release?
Well, pg_migrator already released an 8.4.1 ...
Well,
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
Tom Lane wrote:
Magnus Hagander mag...@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
David Fetter wrote:
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@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
On Fri, Aug 07, 2009 at 04:07:08PM -0400, Bruce Momjian wrote:
David Fetter wrote:
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@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
David Fetter wrote:
This is a pretty serious drawback. If we're going to require that
people send migration scripts when they change the on-disk format,
this needs to be easy.
But, are we?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company
On Fri, Aug 07, 2009 at 05:32:13PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
This is a pretty serious drawback. If we're going to require that
people send migration scripts when they change the on-disk format,
this needs to be easy.
But, are we?
This is an area where we have
Alvaro Herrera wrote:
David Fetter wrote:
This is a pretty serious drawback. If we're going to require that
people send migration scripts when they change the on-disk format,
this needs to be easy.
But, are we?
I think it's a lot more nebulous than that. At the same time I
Andrew Dunstan and...@dunslane.net writes:
I think it's a lot more nebulous than that. At the same time I think the
days when we can blithely change the on-disk format with hardly a
thought for migration are over. IOW, there's agreement things have to
change, but the exact shape of the
On Fri, Aug 07, 2009 at 06:02:32PM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think it's a lot more nebulous than that. At the same time I think the
days when we can blithely change the on-disk format with hardly a
thought for migration are over. IOW, there's
David Fetter da...@fetter.org writes:
I am not suggesting that this change be immediate, and it's not ivory
tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
about the development practices of Oracle, or DB2, or even Mysql?
Tom Lane wrote:
David Fetter da...@fetter.org writes:
I am not suggesting that this change be immediate, and it's not ivory
tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
about the development practices of
David Fetter wrote:
Odds are that the patch submitters will not understand enough to
know how to modify pg_migrator, but just knowing something broke is
usually enough for the hackers group to find a fix.
This is a pretty serious drawback. If we're going to require that
people send
On Wednesday 05 August 2009 06:00:19 David Fetter wrote:
If I'm understanding you correctly, you're saying that pg_migrator (or
whatever actually does this) needs to be an official PostgreSQL
project in order for us to be able to require that people use it. For
what it's worth, I agree.
Is
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
On Tue, Aug 04, 2009 at 05:19:16PM +0300, Peter Eisentraut wrote:
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
David Fetter wrote:
Is it strictly necessary that its release cycles match exactly those
of the database engine, or would it be OK for it to release as needed,
not triggering a major PostgreSQL release?
Well, pg_migrator already released an 8.4.1 ...
--
Alvaro Herrera
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
* Peter Eisentraut (pete...@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
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
On Aug 3, 2009, at 7:57 AM, Stephen Frost sfr...@snowman.net wrote:
* Peter Eisentraut (pete...@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
Andrew Dunstan and...@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.
Tom Lane wrote:
Andrew Dunstan and...@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
Andrew Dunstan and...@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
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
Andrew Dunstan and...@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
On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
Andrew Dunstan and...@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
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
Peter Eisentraut pete...@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
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
David Fetter da...@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,
On Mon, Aug 3, 2009 at 17:32, Tom Lanet...@sss.pgh.pa.us 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
Magnus Hagander mag...@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
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@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
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
On Mon, Aug 3, 2009 at 2:07 PM, David Fetterda...@fetter.org wrote:
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@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
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.
46 matches
Mail list logo
