Simon Marlow
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).
I don't particularly oppose (1) either. I only want to enable fully automatic satisfaction of dependencies with minimal maintenance overhead for all parties involved. In an "ideal world", where that means "everyone will happily follow the convention" in this context, (2) would require a little less maintenance, but (1) isn't so bad. ;)
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.
Valid point. Taken together with your earlier points about keeping the analogy to module imports, I think we might want something like the following in the package description: import: qualified foo[1.1 - 1.3, 2.3] as baz I.e. - Specify a list of known compatible version ranges. - Allow qualified imports with aliasing. Would we also want unqualified imports with aliasing? The details there are not so important to me, I think, but I'd like to make one point which I think is pretty crucial... IMHO, we should _not_ allow unbounded version ranges to be specified as compatible. The reason being that such a statement would in general be false and the build system would not be able to deduce very meaningful information from it. Again, I'd like to see a system possible which I can tell "fetch package foo" and it will fetch it and all its dependencies with a pretty good confidence of everything working fine. If foo depends on bar and specifies "any version later than 1.1", this dependency will break at some point. I think we must clearly seperate the two sides: 1. The author of foo knows some set of versions to be compatible with foo. 2. The author of bar knows, for each version of bar, some set of versions it is backwards-compatible with, e.g. "what works with 1.1 will always also work with 1.2". Both sides specify their knowledge in their respective package descriptions and the build system acts accordingly. In the case where it cannot offer any version of bar that it _knows_ to be compatible with foo, it could (be instructed to) _attempt_ compilation with whatever it has and maybe it will work, but it should not blindly do so and possibly fail (as it would sooner or later if foo could say "I work with everything >=1.1"). Best regards, Sven