planning for ghc-6.10.1 and hackage

[Juan Carlos Arevalo Baeza]

   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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081003/06ef1cfd/attachment.htm