On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler <david@justatheory.com> wrote:
> 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
certainreleases names, but probably not. I’m too lazy, and if a given release has more than one new feature, it’d be a
bitsilly.
>
> 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.
So the idea is that you're actually supposed to separately catalog
each feature you added (e.g. each new function), so that people can
depend specifically on those features. Then if you remove the
function again in some distant future, you stop advertising that
feature (but you can still advertise any other features you added in
the same release). If you're not going to do that, then this feature
as proposed is strictly worse than figuring out a way to compare
version numbers, because it's more work, some people will not bother
to update the provides line, and other people will sometimes forget
it.
I don't really have the foggiest idea how people using other packaging
systems handle this. It seems like it would be a huge pain in the
rear end to be continually adding Provides: lines to RPMs for every
new feature that a new version of a package offers, not to mention
that you'd hardly want the corresponding Requires: lines to have to
enumerate all the public interfaces those packages used just in case
one of them ever went away. I have a feeling I'm missing part of the
picture here, somehow.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
