Neil Mitchell wrote:
Hi
I agree. >= 1.0 isn't viable in the long term. Rather, a specific list,
or bounded range of tested versions seems likely to be more robust.
In general, if it compiles and type checks, it will work. It is rare
that an interface stays sufficiently similar that the thing compiles,
but then crashes at runtime. Given that, shouldn't the tested versions
be something a machine figures out - rather than something each
library author has to tend to with every new release of every other
library in hackage?
The only reasonable way we have to test whether a package compiles with a
new version of a dependency is to try compiling it. To do anything else
would be duplicating what the compiler does, and risks getting it wrong.
But you're right that tools could help a lot: for example, after a base
version bump, Hackage could try to build all its packages against the new
base to figure out which ones need source code modifications and which can
probably just have their .cabal files tweaked to allow the new version.
Hackage could tentatively fix the .cabal files itself and/or contact the
maintainer.
We'll really need some tool to analyse API changes too, otherwise API
versioning is too error-prone. Anyone like to tackle this? It shouldn't
be too hard using the GHC API..
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
