
The problem is that nothing breaks immediately. Then someone else comes along and transitively depends on your package and on another package, which depends on the newer version. Your users wind up with strange conflicts like that if they are using Parsec 3 they can't use HTTP. Or if they use fc-labels they can't use any library that internally uses mtl, because fc-labels uses transformers. Or worse they want to use a library that used fc-labels internally with another library that used mtl internally. It fragments the library base that you are able to use. Version caps are not the answer. -Edward Kmett On Tue, Jun 8, 2010 at 2:21 PM, Gregory Crosswhite < gcross@phys.washington.edu> wrote:
Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks.
Cheers, Greg
On Jun 8, 2010, at 11:08 AM, Gene A wrote:
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart
wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including:
* QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...)
(... * No additional breakages are introduced. ...)
Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!!
cheers, gene
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe