Re: deprecating contrib for PGXN - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: deprecating contrib for PGXN
Date
Msg-id BANLkTi=kZ_XXCpB3=-PT4k39vmNUudACew@mail.gmail.com
Whole thread Raw
In response to Re: deprecating contrib for PGXN  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: deprecating contrib for PGXN  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
On Wed, May 18, 2011 at 14:49, David E. Wheeler <david@kineticode.com> wrote:
> On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
>
>> I don't see why it couldn't, at least for a fair number of
>> extensions.. It does require the ability to differentiate between
>> patch releases and feature releases, though, which I believe is
>> currently missing in pgxn (correct me if i'm wrong), but that's a
>> solvable problem, no?
>
> PGXN requires semantic versions. If authors use the correctly, then you can rely on the z in x.y.z to be a patch/bug
fixrelease, and the y and z to indicate new features. 

Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
time? I somehow got the idea that old versions were removed when I
uploaded a new one, but I happy to be wrong :-)


>> Also, if it has several extensions, it should generate several DEB's -
>> assuming they're independent extensions, right? If so, where's the
>> problem?
>
> Maybe they're not independent. But why is that a problem. There are a *lot* of DEBs with multiple Perl modules in
them.

Yeah, I don't see the problem if they *are* dependent.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Why not install pgstattuple by default?
Next
From: "David E. Wheeler"
Date:
Subject: Re: deprecating contrib for PGXN