Re: ALTER EXTENSION UPGRADE, v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-11 20:46:53
Message-ID: 19985.1297457213@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think it'd likely be sufficient to bump them only once per release
>> cycle, ie, there's no need to distinguish versions that never appeared
>> in the wild. But if we forgot and created 1.1 early in the 9.2 release
>> cycle and 1.2 late in the cycle, there's no great harm done either.
>> What I don't want to be doing is creating artificial version bumps with
>> empty upgrade scripts in every release cycle --- that's make-work for
>> us, and make-work for our users too.

> I would favor different release cycles for extensions than for the core
> product. It's a technical fact that a single extension source can and
> do support more than one major core version. And as soon as the code is
> maintained, next extension release would happen at next minor upgrade
> release.

Anything that got kicked out to pgfoundry would presumably start acting
that way. Anything that's part of core git is going to stay on the same
release cycle as the core, thank you very much. Release engineering is
a big enough headache around here already.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-02-11 20:49:17 Re: ALTER EXTENSION UPGRADE, v3
Previous Message Kevin Grittner 2011-02-11 20:46:09 Re: Sorting. When?