From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Darren Duncan <darren(at)darrenduncan(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: deprecating contrib for PGXN |
Date: | 2011-05-18 18:49:27 |
Message-ID: | 77C3E437-D197-4BED-BF66-2635F12200CE@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 fix release, and the y and z to indicate new features.
> 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.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-05-18 18:57:33 | Re: Why not install pgstattuple by default? |
Previous Message | Magnus Hagander | 2011-05-18 18:47:25 | Re: deprecating contrib for PGXN |