[Hugs-bugs] RE: the woes of non-cvs haskellers

[Simon Marlow]

> To give just one concrete example, what packages do I 
> recommend to someone wanting to learn a bit of Haskell, and 
> do some graphics and perhaps windowing, on Windows?
> 
> - Hugs (Winhugs bug in current binary release, so better avoid
>         that and use plain Hugs?)
> - HGL (does it work with latest Hugs/GHC, or do I need older 
>         versions? which ones?)
> - GHC (current binary release seems to have serious probs on 
>         some Windows versions; has also seen some rapid 
>         development breakage recently, e.g., TH syntax, forcing 
>         other packages to play catch-up just to get working again)
> - wxHaskell (works with ghc-6.0.1, will it work with 6.2? what about 
>         Hugs? what about ghc-6.4?)
> - some generic text-editor (but on Windows98, the way that .hs
>         files are associated with Hugs/GHC cannot be modified in
>         the standard dialogues, as they can for other associations, 
>         so how do I associate .hs files with an editor? I wouldn't 
>         want to recommend some beginner editing the registry for 
>         that purpose..)
> 
> The issues are usually small, but there are many of them, each
> package has its own, and all too often the response is "fixed in 
> CVS, will be in next release".  
> 
> Of course, the next release is a while a away and by that time, 
> there'll be a different set of small issues plagueing the next set 
> of binary releases. So, just getting someone started requires
> careful investigation/testing and some thinking (instead of: 
> "just download and install the latest Haskell starters set").

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.

There's always going to be a tension between doing lots of bugfix
releases and releasing new development versions so that people can get
access to new features quickly.  We only have limited resources - and we
like to do a bit of development & research too, rather than just fixing
bugs and doing releases all the time.  So we arrived at the current
policy, which is...

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 :-)

Meanwhile, we can continue development on the main branch (the HEAD).
Due to our lack of resources, we can't do releases off both the stable
branch and the HEAD (otherwise there would have been a 6.0.2).  In due
course, the HEAD turns into a new major release (6.4) and so on.  We
think this is a reasonable compromise and makes good use of the
resources we've got.

Remember that 6.2 is a new major release, and has had zero time to
mature.  So it's likely there are going to be bugs in it (eg. the
Windows ME problem).  6.2.1 will follow shortly, and fix all/most of the
issues that were reported without breaking code that works on 6.2.

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.

Cheers,
	Simon