daveg 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 long-time user of
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
> Andrew Dunstan 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 st
Tom Lane wrote:
> Andrew Dunstan 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 o
On Saturday 08 August 2009 01:28:34 Tom Lane wrote:
> David Fetter 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 developmen
On Fri, Aug 07, 2009 at 06:28:34PM -0400, Tom Lane wrote:
> David Fetter 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 dev
Robert Haas wrote:
> On Aug 7, 2009, at 11:50 PM, Bruce Momjian 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 fi
On Aug 7, 2009, at 11:50 PM, Bruce Momjian 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 serious drawback. I
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 s
Tom Lane wrote:
David Fetter 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 eve
David Fetter 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?
On Fri, Aug 07, 2009 at 06:02:32PM -0400, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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 change is not yet cl
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 th
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
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 Compa
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 writes:
> > > > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> > > >> And I doubt we'd bother generating pg_migrator bu
David Fetter wrote:
> On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> > David Fetter 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 i
Tom Lane wrote:
> Magnus Hagander 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
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
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 ...
Wel
Robert Haas wrote:
> On Mon, Aug 3, 2009 at 2:07 PM, David Fetter wrote:
> > On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> >> David Fetter 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
On Fri, Aug 7, 2009 at 11:35 AM, Bruce Momjian 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 need
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
> >
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.
>
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
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
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 c
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
On Mon, Aug 3, 2009 at 2:07 PM, David Fetter wrote:
> On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
>> David Fetter 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 rele
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 d
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> David Fetter 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_mig
Magnus Hagander 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 ar
On Mon, Aug 3, 2009 at 17:32, Tom Lane wrote:
> David Fetter 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
David Fetter 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 vo
On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> David Fetter 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 w
Peter Eisentraut 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 t
David Fetter 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
On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
> Andrew Dunstan 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 t
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
> Andrew Dunstan 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 st
Andrew Dunstan 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 c
Tom Lane wrote:
Andrew Dunstan 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 t
Andrew Dunstan 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-und
On Aug 3, 2009, at 7:57 AM, Stephen Frost 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 number and build
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
* 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 sho
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
46 matches
Mail list logo
