<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
JCAB<br>
<br>
Bulat Ziganshin wrote:
<blockquote cite="mid:1682226319.20081003194425@gmail.com" type="cite">
<pre wrap="">Hello Simon,
Friday, October 3, 2008, 12:55:34 PM, you wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>