This is exactly what the Package Versioning Policy is for. By using
semantic versioning, your .cabal file can specify that you use version
1.0.* of a given package. Any API-compatible versions of that package are
supposed to be in the 1.0 range. Versions 1.1 and above are considered API
incompatible.
On Tuesday, January 26, 2016, Imants Cekusins
Stack may already do something like this, I don't know. Anyway, here is an idea.
Currently .cabal lists version or version range.
What if package info included lists of API-compatible versions of this package?
Let's say one library requires v10 of packageA. Another library requires v15 of the same packageA. This is a hypothetical scenario :-P
However v10, v15 are API-compatible as far as package maintainer knows. Package info specifies v10 and v15 as API-compatible too.
What if it were possible to issue: cabal install packageA .. and then if v10, v15 are compatible, v15 is returned without warnings. If v10 and v15 are not compatible, cabal would warn.
Basically instead of library clients needing to test multiple library versions or requiring 1 exact version, deps could be specified as 1 version (with which development took place) and cabal (with hints from package maintainers) would figure this out.
It might even be possible to fine-tune it to check modules & symbols actually used by library consumer app.
? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- -- Dan Burton