On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler <da...@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 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers