Duncan Coutts <duncan.coutts@worc.ox.ac.uk> writes:
All,
On reflection, we (Don and I) think we've asked a question that has too many assumptions behind it that are not universally agreed. Perhaps we would do better to look at the slightly more general issue.
The question we asked about API stability in minor releases already assumes a lot about the frequency of major and minor releases and indeed what a major or minor release actually is; what their purpose is.
My two cents: My understanding of the purpose behind the Haskell Platform project is that it: * provides a convenient installer * provides a batteries-included set of "canonical" libraries, with a lukewarm guarantee that the libraries work and have been tested together. The concrete problems that we're trying to solve: * bootstrapping a functioning Haskell system (with cabal & a reasonable library set) is a multi-step, time-consuming process * hackage (thankfully) has a low barrier to entry, but that also means there's a mishmash of stuff there in varying states of quality/testedness/"only-works-with-ghc-6.6"-ism. Evaluating the quality of a library can be difficult for non-experts. * cabal is pretty poor at handling dependency conflicts. I've wiped out & reinstalled the entire haskell stack more times than I would have liked over hard-to-resolve dependency conflicts, and I can't be alone in that. A goal of HP is to ameliorate that. If we're talking about the definitions of major vs minor releases, I'm in the camp that says that if you depend on a major version of the haskell platform, your code should recompile cleanly against minor releases on that line (i.e. no backwards-incompatible changes). For a minor release, bugfixes are clearly okay, new features or modules are probably okay (if limited in scope), and API changes are a no-no. I suspect this meshes with most people's common-sense understanding. *** Something that isn't clear to me is: how are we going to encourage people posting libs to Hackage to target the platform? As a library author, it would be really nice to be able to say: Build-Depends: haskell-platform >= 2009.2 && < 2009.3 and then be able to "import Network". Instead you get: Foo.hs:3:7: Could not find module `Network': it is a member of package network-2.2.1.1, which is hidden If you want to target the platform as a library author, then you have to go through your long laundry-list of dependencies and assign an exact version to each, and you have to repeat this process every time a new version of the platform comes out. I reckon that for many people, the cost/benefit analysis is going to come out to "I can't be bothered." Can this be fixed in cabal? Should we export a module "Haskell.Platform" that re-exports all of the platform modules? (That's a modest proposal, of course, compilation time would go through the roof, but it'd be convenient, and unless I'm missing something "convenient" is the raison d'etre here.) G. -- Gregory Collins <greg@gregorycollins.net>