Duncan Coutts
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