Re: the woes of non-cvs haskellers

>It's been a rough ride in a few ways recently.  But let me try to
>explain our policy and why it's a good compromise, and hopefully this
>will shed some light on why there might be problems going from GHC 6.0.1
>to 6.2, for example.

just to clarify:

- I'm not complaining about your or anyone else's policy (well, not in 
    this thread, anyway;-), especially when they're dictated by limited
    resources, and so many good things are produced in spite of such
    limitations!

- I'm aware of the LIP, but it has been a long time in the making,
    probably because it tries to address lots of issues

- what I'm trying to point out is that the current situation shows that
    there are some serious bugs in the system, even for the minimal
    core (Haskell starter pack = Haskell implementation + some GUI lib)

- what I'm hoping is that there might be some small issues at the root,
    and that addressing those would give us a less bumpy ride until
    the LIP arrives at its goals

>We start a new *major* release every so often (eg. 6.2 is a major
>release).  It has new features, and might change the interfaces to
>libraries and tools.  At this point we branch the codebase.  We then do
>a number of patchlevel releases (6.2.1, 6.2.2 etc.) that fix bugs
>*only*: i.e. it's highly unlikely that these releases introduce new
>bugs, and they definitely don't change interfaces.  So those after
>stable binary releases can follow these patchlevels and get a
>monotonically improving experience :-)

Knowing that, I tend to avoid the first version of each new major 
release:), but this general scheme has at least two problems at the 
moment, and especially the assumption in the last sentence 
above is, unfortunately, no longer true:

1. patchlevel releases have a lag time of a month or more
    even after "serious" bugs (remember that even trivialities like 
    the winhugs problem look serious to beginners), suggesting 
    that "just packaging up a patchlevel release" may not be as 
    simple as perhaps it should be, even after the bugs are fixed.

    As patchlevel releases tend to appear only for the latest 
    major release, because of the lack of resources, developers 
    have to move with the major releases.

2. developers of tool X have little control over what versions 
    of other packages/tools/implementations users have installed:

    - there are universities that only permit updates of the 
        basic implementations between semesters/years, to 
        provide stability

    - there are always new enthusiastic Haskell users, who
        naturally (try to) start from the latest set of versions

    - users generally use more than one tool/library, so they
        need to find a set of releases that works together

    - new major releases often fix bugs for which there's no
        simple work-around, so some developers depend on
        the latest implementation to get their package working

    - all developers suffer from lack of resources, so some
        packages might be updated less frequently to the 
        changes introduced with the latest implementations
    
    Developers have to cater for what the installed base,
    summed over all their users, dictates.

What makes the ride a bit bumpy at the moment is that there's
no stable set emerging among the updates, so everyone is
more or less forced to follow the latest developments in each
of the packages they or their users are concerned with.

As a tool developer, that means I'll get bug reports telling me
that my tool doesn't build with the latest version of X, so I can't
rest of my older stable version of X. As a Haskell promoter,
that means I'm having a really hard time recommending what to
download and install ("hugs, but don't use winhugs; ghc, but
not the latest version; HGL/wxHaskell, perhaps, but one may 
not work with hugs, the other possibly not with ghc, or do they,
and perhaps the versions and your system are important, hemm, 
let me check..").

It was the second role that alerted me to all the workarounds
and uncertainties I had grown used to but which I can't impose 
on a newcomer.

> We think this is a reasonable compromise and makes good 
> use of the resources we've got.

Generally, it works very well - indeed part of the problem is
that it's hard to keep up with you at times;)

Cheers,
Claus

>Also remember that certain features like TH are deemed experimental, and
>fixing their interfaces too soon would give us an undue maintenance
>burden.  If you use experimental features, be prepared to do some
>conditional compilation based on compiler versions.

The TH syntax leakage affected programs that never even used TH.
But that's yesterday's news