Simon Marlow wrote:

The proposed policy, for the sake of completeness is: x.y where:

x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical [..] dependencies must specify a single x.y API version, or a range of versions with an upper bound.

What about x == 0? I mean, the intention of 0 is that 0.1, 0.2 and so on may well overthrow the API. But that's a bikeshed issue. ChrisK wrote:

The above declaratively expresses that libcurl-3.3.0 provides the version 3 API and the version 2 API.

Good idea. In the end, both proposals are based on the same observation: the dependency knows best which of its versions are compatible and which aren't. It's *not* a responsibility of the dependent package to know that. It only has to know one particular version it compiles against. So, it would just specify "I do compile with foobar 1.2" and let foobar 1.3 decide whether it's compatible with 1.2 or not. Given Simon's proposed policy, the answer would be "yes", if it were not for possible name clashes:

However, there's an important difference between shared-library linking and Haskell: in Haskell, a superset of an API is not backwards-compatible, because it has the potential to cause new name clashes.

Solution? explicit imports? explicit module signatures with subtyping? implicit signature conversion foobar 1.3 -> foobar 1.2 on the package level? Regards, apfelmus