   How can you _reasonably_ put in a high bound if future versions of a library (which might, or even most likely, work with yours) aren't know at the time the limit is put in place? Basically, if you want certainty, >= must be deprecated or eliminated altogether, and the only reasonable thing is (maybe multi-choice) ==, so you can communicate which _discrete_ versions you've tested with it. After all, even minor revisions contain bug fixes, and it is all-too-possible that you might rely on buggy behavior inadvertently.

   It would be awesome if packages could somehow advertise which older versions they _should_ backwards-compatible with. Cabal/GHC should still pick the closest available match to a version explicitly mentioned by your library (rather than the newest one), and report all risky (non-identical) choices in case of build failure. Reports like: "Possible reasons for failure: base package version requested was 3.2 but the closest match found was 4.1, which didn't advertise backwards compatibility; stm package version required was 2.1, but the closest match found was 2.3 which does advertise backwards compatibility but might be in error". That way people with their own library mixes can hope for the best, brace for the worst and get actionable "go install those requested versions, you dummy" info in case of failure.

   It would also be awesome if hackage could be a conduit for peer verification of library version compatibility. It would be awesome if cabal could be used to communicate to hackage a successful build with a previously-presumed-risky combination of libraries, so that hackage could update the script appropriately. I suppose you'd want more than a single report (say, three reports) before updating the package to claim compatibility with each specific library version, but that's in the realm of the details.

   And don't forget platform compatibility. A particular library could work with package X version 3 or 4 on Windows, but require version 4 on Linux. Maybe in version 4 of the package they substituted hardcoded ++ "\\" ++ with portable </> or something silly-but-deadly like that.

   I guess my point is that, if you want cabal to make a dependable determination of whether a package mix will work well together, then you need sufficiently rich info, and simple version comparisons just won't cut it.

JCAB

Bulat Ziganshin wrote:

Hello Simon,

Friday, October 3, 2008, 12:55:34 PM, you wrote:

Perhaps we could even go as far as saying "base >= 3.0" is equivalent to
"base == 3.0.*".  i.e. if you don't supply an upper bound, then we'll give
you a conservative one.  I wonder how much stuff would break if we did that.


this looks reasonable for any package yjat follows versioning policy
since changing major number means that anything in api may change

you may use this as "theoretical" foundation for such trick :)  of
course in the future it will be great if people will start to use
intervals with both high and low bounds