Platform policy question: API compatability in minor releases

Claus Reinke claus.reinke at talk21.com
Sun May 10 18:00:04 EDT 2009


> The Haskell Platform concept calls for major and minor releases.
>
>      * The point of major releases is to update the set of common
>        packages we all use. That is, to specify which packages and
>        which versions (corresponding to APIs). The target is to have
>        major releases every 6 months.
>
>      * The point of minor releases is to support a major release across
>        a range of operating systems over time and respond to bugs that
>        are discovered in a library or tool subsequent to their release.
>        The target is to have 2-3 minor releases after major releases at
>        intervals on the order of 4-6 weeks.

I suspect this is too simple a picture of what people expect from the HP!-)
Some examples:

- stability: used to be about language stability alone, but these days,
    libraries are a big part of the game, language standards are a bit slow
    in keeping up with language extensions, and GHC releases no longer
    come with a "standard" kitchensink of extensions and libraries

    Here, the question is: can I write code/documentation wrt HP x.y.z,
    and will the combination remain accessible, useable, and relevant?
    And which stability problems does the HP not address/solve?

- accessibility: there are still gaps in Haskell users being able to
    build Haskell infrastructure from scratch on arbitrary platforms (foreign
    libraries, autoconf, tool dependencies, inconsistent/late propagation of
    Haskell software into OS package managers, ..).

    Here, the question is: for the code someone writes/for the code someone
    wants to use, is there a HP x.y.z that will suffice to get things started?
    What are the remaining gaps, and what can be done to close them?

- simplicity: there are currently many many different ways to set up and
    maintain Haskell infrastructure, and they don't necessarily work together
    (if you use cabal install, your native package manager doesn't know; if
    you use the native package manager, you may not be able to get the
    code or versions you need; if you build GHC head yourself, binary
    releases of GUI libs are no good; if you manage to get everything
    working and want to make a cross-platform release, you have no
    idea what difficulties your users may run into trying to set up the same
    baseline on their platforms; and so on, and so on..).

    Here, the question is: is the HP sufficient as the one-and-only baseline
    for Haskell infrastructure, ie, can everyone everywhere start from there,
    pushing the problems above one level further away, to the non-HP libs
    and tools? And what are the recommended routes for going beyond
    this common baseline, in light of the gaps mentioned above?

There are probably other usage/intention patterns than these, and I'm not
sure that different patterns lead to the same conclusions/preferences when
it comes to policy decisions. So I suggest that everyone states the patterns
they have in mind when suggesting particular policies, and keeps an eye
open towards other patterns that these suggestions might be less suitable for.

Even within the currently defined range of HP libs and tools, not everything
is the same: as we know from experience with earlier GHC releases, there
are core libs (both provided and used internally), and there are extralibs
(provided, but not used internally). As the HP grows, one might want to
add a dependentlibs category (used internally, but not quite as essential
as core libs). And we've got the situation that some tools are also not
quite independent (eg, GHC Api clients like Haddock are currently deeply
entwined with GHC version and build process).

This affects update routes: core libs and tools cannot be updated without
updating the whole HP, dependentlibs can only be updated together, and
extralibs can be updated. Of course, part of the rationale for the HP is
that updating is not always a simple matter of doing 'cabal <DWIM>'..

For non-core libs and tools, it might even be possible to provide multiple
internally consistent sets of versions within one HP version, so instead of
having branches of HP versions, a single branch of HP releases could
provide both stable and latest versions.

I guess what I'd like to say is that it might be better to look for a map
of the design and usage spaces first, as well as the remaining issues that
keep cabal/hackage from being 'the last suit you'll every wear' before
delving into policy decisions.

Claus

<DWIM>: do what I mean;-)






More information about the Libraries mailing list