On Apr 5, 2011, at 1:42 PM, Aidan Van Dyk wrote:
> Sure, but if you want, the "feature" you can provide can be something like:
> pgtap-1.0 (or any of pgtap-0.2{0,1,2,3,4}).
>
> And if your package is backwards compatable, it could even provide:
> pgtap-0.25
> pgtap-0.24
> pgtap-0.23
I see, I get it.
> And that also means that you don't have to screw every body over when
> some future pgtap-123.45 is no longer compatible, and the extensions
> have relied on "$VERSION > 0.23" meaning they'll work with it.
I see.
> I mean, PG itself is an example. Does pg > 8.4 mean your code will
> work with all future (or even past, but > 8.4) PG versions?
I see. So the extension author can more easily tell users when compatibility
has been dropped for something. That makes sense.
> As someone who has had to try and deal with "package versions" for
> dependencies in RPM and DEB, and been through the hell that is open
> source package variants, all with the ability to turn on/off features
> at configure/compile time, a just versions even with <, <=, =, >=, >
> all mapped correctly isn't good enough.
Yeah. The use of an implicit >= in CPAN modules has been a decent 90% solution,
but it does cause headaches for people that they can't express things better.
The ability to do so would require a mini-language with more operators,
precedence, grouping, etc.
> Of course, I'ld love for extension in 9.1 to provide a basic
> provides/features for my extension to give, but if that train has
> already left the station, I don't have much choice ;-(
Yeah, but the way it is doesn't break the ability to do it later. I suspect
that Dim and Tom will be thinking about it for 9.2.
Anyway, your post helps me to understand things better, and so I'm less
insistent about imposing a version numbering scheme now (though I still think
it would be more useful to have one than not).
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
