On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen
Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too.
I'd really like to see hackage separated into a couple of separate instances based on general stability. I think it's wonderful that anyone can easily push a new app/library, and have it available to virtually everyone via cabal-install. However, that ability caters to a completely different use case than John's maintenance / production dev. scenario. Something akin to the Debian stable / unstable / testing division would be nice, so that production code can avoid dependencies on packages that are very quickly evolving, and so that those evolving packages have the freedom to move through a series of breaking API changes before settling on the "right" solution and moving to a more stable package store. --Rogan
I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well.
-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe