Stefan Karrmann wrote:
My 2 cents:
Sven Moritz Hallberg (Sun, Jul 16, 2006 at 01:24:43AM +0200):
[...] She must specify it somehow. Two possibilities come to mind:
1. Add a field to the package description of foo (v1.4, say) that says "I'm backwards-compatible with 1.3." When building, this relation would have to be inspected to see whether any currently installed version of foo satisfies the dependency specified by the mount. 2. Declare a convention for version numbers to carry compatibility information, like the OpenGL standard, for example: If the new version is backwards-compatible, only the minor version number changes. If it isn't, the major version number must be incremented.
I prefer 1. The FSF use 2 for its GNU software and others started with it, too. But after a while most of them tend to increase major numbers. E.g. 3.0, 3.11, 95, 98, 2000
I think we should do (1). But we should also keep the current mechanism of allowing a package to specify a range of dependencies, the reason being that even when an interface upgrade isn't fully compatible, the package might still work with it, and this is a property of the consuming package, not the package that is depended on. (incedentally .NET has both of these facilities too, but only for runtime dependencies, not build-time AFAIK). Cheers, Simon