| From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Finer Extension dependencies |
| Date: | 2012-03-29 17:48:34 |
| Message-ID: | D2CA6B37-3A52-4A28-B98D-F5EE2D24C700@justatheory.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mar 29, 2012, at 4:42 AM, Robert Haas wrote:
> 2. Add a new feature to the provides line with every release that does
> anything other than fix bugs, leading to:
>
> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
> foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3,
> foobar-3.0, foobar-3.1
This is what I have expected to do. In new releases of pgTAP, I’d probably just add version lines. I might give certain releases names, but probably not. I’m too lazy, and if a given release has more than one new feature, it’d be a bit silly.
I’ve never been very keen on this approach, but then I don’t understand packaging systems very well, so it might rock, and I just don’t know how to use it properly. But I cannot tell.
Best,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-03-29 17:57:19 | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
| Previous Message | Andrew Dunstan | 2012-03-29 17:46:39 | Re: patch for parallel pg_dump |