[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[Michael Sloan]

I agree that Haskell's design gives us a good leg up on the problem of
acquiring and comparing APIs. However, I don't think that this
manifest solution really buys us enough to justify the complexity.

There're also some specific, perhaps resolvable, but unsightly problems, which
I outline here:
http://www.reddit.com/r/haskell/comments/ydtl9/beyond_package_version_policies/c5uro04

(also another pitch for my proposed solution to this variety of problems)

-mgsloan

On Fri, Aug 17, 2012 at 2:34 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan <bos at serpentine.com>
> wrote:
>>
>> Any vastly more complicated and detailed versioning scheme has a huge
>> burden to prove that it won't collapse dramatically more quickly. (Frankly,
>> I think that anything involving "specify every detail of your known
>> dependencies" is dead on arrival from a practical standpoint: it's way too
>> much work.)
>
>
> If you do it in terms of hashed signatures, you can make the compiler and
> toolchain do the work for you.  The problem with version numbers is that it
> *is* manual.  It can't catch behavioral changes, though; you probably need
> some kind of epoch override for that in the case where it doesn't come with
> corresponding API changes.
>
> The reason it's never done is that you can't really do it with C or C++.  We
> can mostly avoid that (the FFI is an issue, but it is anyway:  cabal can't
> really check C stuff, unless you use pkg-config which was two operating
> modes:  exact versions or no versioning).
>
> --
> brandon s allbery                                      allbery.b at gmail.com
> wandering unix systems administrator (available)     (412) 475-9364 vm/sms
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>