Duncan Coutts wrote:
On Thu, 2007-03-15 at 23:25 +0300, Bulat Ziganshin wrote:
the beauty of this proposal is that we can issue 3rd, 4th and any other version based on real users feedback. including some module into base means stopping of its active development, you can see the situation with ByteString
You keep saying this but I really do not think it is true.
One can hardly claim that active development stopped with ByteString's inclusion in base! On the other hand, I do think including it in base made contributing and participating more difficult. I used to track the development version, and my code could depend on specific versions, etc. Upgrading 'base' is much harder, and I've basically given up on that, and just wait for the next GHC snapshot, even if it means I have to implement 'groupBy' separately. Also, switching back and forth between being a separate package and a part of base complicates dependencies: code that used to depend on the 'fps' package suddenly breaks when the package is part of 'base', and to be compatible with both worlds, I need to juggle different cabal files. In the end, I just made a dummy fps package satisfying the dependency.
We probably will not get around to doing that before 6.6.1 since we're working on other things at the moment but the point is that we could.
You could change it, but it'd be hard for us mere users to pull it, test it out, and perhaps revert to the old version. As a separate package, it's just a few ghc-pkg's away. But regardless, if System.Filepath is well defined enough that it won't be updated, it doesn't matter where it goes. Presumably, it wouldn't have to be so hard: base could conceivably be more upgradeable, and cabal could grow backwards-compatibility functions for packages that are split or merged. (Are there other reasons for stuffing things in base than cyclic dependencies with other modules in it, btw?) -k