Proposal: register a package as providing several API versions
apfelmus at quantentunnel.de
Tue Oct 16 09:48:19 EDT 2007
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.
> The above declaratively expresses that libcurl-3.3.0 provides the version 3 API
> and the version 2 API.
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
> 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?
More information about the Libraries