Comments on "Are releases stable enough?"

Never had any problem with any stable release.
A have had a few issues with stable releases in the past but after reporting the issues the next stable version has always included fixes.
ghc is a great tool! It is having a huge impact on functional programming research in general, and I think it's also probably improving the prospects for FP in the real world.
At least for my purposes
I've only had one showstopper till now: the 6.2.1 garbage collector bug. Fixed in 6.2.2.
i found just two problems after half-year of everyday GHC use. one is that GHCi can't load my compiled modules and second is about calling into Haskell from multiple C threads. Please write to my email, because i can't send bug-report to you :) (nor to Hugs developers :) in all other aspects GHC works FINE
Or at least they seem to be. One glaring error in 6.4: the redefinition of GT in the Data.Generics package.
The problem is not so much with GHC, but with the brittle dependency on particular builds of GHC exhibited by some ancilliary packages, e.g. wxHaskell. Can't invest time on things that will break (even if temporarily) when I upgrade GHC, which I will want to.
I tend to be conservative in my usage, however. (Maybe if I used more of the cutting-edge features I would get cut more often?)
Never had a problem with bugs in the compiler.
Definitely yes.
never had any real problems.
there are some annoying problems (ie compilation errors on *.hc intermediate files); it happens always when I am just in hurry
I have not had any problems yet except for external libraries (HSQL) not working with the package format changes in 6.4.
I have never seen a segmentation fault or a crash or anything like that, so it is more than stable enough for me.
I didn't have any issues, but I am not using it for professional purposes.
though I suspect 6.4 will need to keep it's Release Candidate state for a while.
I remember some legacy things (like ghc-pkg -l) being replaced or augmented in a backward-incompatible way. Worse, some of badly designed features are replaced by other hacks. Example: One thing that is broken in ghc-pkg description is the extra_ld_opts field which should contain options that the linker understands. Instead it contains options that are undestood by gcc. The driver should add the popper prefixes itself since I as a user don't know that gcc is used underneath. How is this going to work if c-- is used instead of gcc? It would be nice if most features of ghc could be checked without reverting to comparing the version number.
Haven't experienced trouble with released versions of GHC. GHC 6.3 was a bit of a moving target, though (see previous question).
New releases are stable, but API breakage between versions is quite frustrating! I understand that there's always tension between freezing an API and breaking backward-compatibility to fix problems, but I see a lot of effort spent on upgrading old libraries to work with new GHC versions. It's hard work to pick up a three-year-old Haskell program and get it to work with new versions of GHC!
I run into fewer problems with GHC than most of the commercial compilers I have used. Excellent work.
for the newer releases, yes; previously doubtful.
but almost. And often the problem isn't GHC's fault but other things (Hat, HMake, Alex, Happy) being incompatible with the GHC upgrade.
GHC does have bugs every now and then but my experience is that it is in very dark corners and I am almost never affected by these. In my experience GHC is very solid.
You can never be stable enough! <smiley> Perhaps GHC would benefit from a dual-train (stable + development) approach?
I've been pretty pleased with 6.2.2 and it having been around for a while is fine.
I haven't had any problems except with experimental extensions. On that note, I'd like to see more fine-grained command-line options to enable specific extensions -- with only --fglasgow-exts it's too tempting to use experimental features that are half-baked and/or are unlikely to be included in the next version of standard Haskell.
Well, I'm not using it often now...
Although I did not test 6.x thorougly
There are few non-backwards compatible changes from release to release. Even though that can be a pain in the rear, that goes a long way towards easing the tensions of new releases (ie. "will this release break my current code?").
I have experienced no stability problems.
A few releases are stable. It is better to do 3 times less of releases, but make them more stable.
I don't really know, as I do not use the advanced features.
So far, I haven't had a problem, but I haven't reached much of the edge of the language.
I haven't had any problems so far, but then again I'm not the one installing them on Solaris... ;)
Absolutely, it is amazing how well it all works. Well done!!
Yes, but I don't use much more than H98 + Concurrent. Can't speak for more adventurous users...
My only recent experience is with the 6.4 release, which was problematic.
never ran into problems with releases that are marked "stable"
They are stable enough for me. For GHC-6.4, I'm not too enthusiastic about the non-backward compatible change in the package system, and I think that it would be really nice if library moves would not so easily break old programs. OTOH, I would really like to mention that the long public release candidate testing phase of GHC 6.4 was very helpful and probably helped to find a lot of problems prior to the final release.
The releases I've tried have seemed very stable.
Releases themselves are stable enough. But some kind of "migrating your programs from version x.x" document would be great.
Never had any problems.
As a matter of policy, I nearly always wait a few months for software releases to stabilize (not just GHC's!).
Haven't seen any problems, but haven't done any hard nor large sw with Haskell, yet.
Hope so
Although for many releases now the documentation has stated that the ability to create Haskell DLLs in Windows is broken - I'd like to see that feature working again.
I actually don't know, but there is no option for that.
The version that I'm using, 6.4, hasn't crashed yet. Of course, I've only run hello world so far, so that may not be too impressive. :-)
Things could always be improved, but ultimately, yes, stable enough, especially given the usually very rapid response from the GHC developers to various kinds of problems.
I haven't found any bugs yet.
I have no problems.
one exception: 6.4 package tools are not compatible with earlier versions - language is ok
Bugs rarely show up, and if they do, it's mostly due to buggy source code. I've never encountered a bug that kept me from compiling a correctly stated program.
I expect bleeding edge use of Haskell to break, and non-bleeding-edge use seems to be pretty stable these days.
until now, no problems.
Not really sure yet - but expiriences so far are very good.
Still on "make"...Stable so far!
6.2.2 was good for me
Sorry, not enough experience w/GHC yet.
I can't remember it ever crashing on me.
For what I do GHC is stable enough. Of course it could always be more stable :-)
Never had a problem with stability.
I'm using 6.2; have had no problems.
yes, definitely.
Releases are usually very stable, but if one needs a bugfix - that is usually included in HEAD very fast - waiting for the next stable release can take very long.
I have not had a lot of experience with ghc in recent years, but have always found it to be a good quality compiler, and have not noticed any change.
"The impossible" happens quite often. :)
I have had no problems.
The only small bug I found was due to a syntax error not properly handled and was corrected within 24 hours :)
Though I do wish for more QuickCheck tests in the test suites, I don't yet wish hard enough to write them myself.
On the whole
I haven't tried 6.4 yet.
Very stable.
I hardly use it for anything serious. Soon, though, I hope!
But I would like a more detailed analysis of "what this may break" in the relase notes.
I would like better support for backwards compatibility. E.g. please deprecate features for at least two releases (over at least 12 months) before removing them. ghc 6.4 removed a lot of features which were not even deprecated in 6.2.2.
Non back-compatible library changes are bad.
Releases seem very stable to me.
Although... there have been problems with GHC on newer architectures, such as x86_64. In particular, bootstrapping has been a problem for me, as well as compiling some libraries (HSQL) that specify -split-objs, which isn't yet supported on AMD64.
I have never had any stability troubles.
Haven't exercised them enough to be able to tell.
In the time I have been using it, I have had no significant problems with new releases.
No problems with that
... but sometimes it is work to adapt to new releases (especially if low-level things like OS calls are involved)
Never seen a crash.
on the rare occasion I find bugs, they are always quickly fixed.
mostly yes, except ghci on debian/powerpc
More stability would be welcome. but it is extremely rare for us to run into a problem that is a GHC bug.
Just switched to 6.4, 6.2.1 was very stable.
For me they are, but I stick to the straight-and-narrow, ie. I don't dabble much in language extensions.
I only once had a problem with the compiler - the program would bomb when a great deal of memory was used.
in general, yes, but testing on windows starts too late in the release cycle, resulting in more problems with releases on that platform.
Stability has been a strong point. The only recent exception being the integration of Cabal into 6.4. (Putting it into 6.4 certainly lit a fire under the libraries group to finish something, so this was perhaps unavaoidable.)
Very stable as far as I've seen.
I never had problems with stability. Occasionally I hear people complaining about something that might be a stability problem, but that has never been confirmed when tracking down the cause
I haven't seen any unstableness, but then I haven't used ghc that much so far.
6.4 has quite a few problems.
Not had any stability issues
Altough the intermediate versions are often *very* unstable.
I did not answer the Features I did not yet use. Thanks for the poll
Using GHC 6.2.1 I was often getting: Stange closure type ... error
Haven't tested 6.4 yet extensively.
Actually, no, but that's entirely the fault of people (including me) not testing prereleases for various reasons. You certainly shouldn't have delayed 6.4 more.
Yes, so far.
Mostly. I've been getting odd messages and crashes out of my Markov chain program and I haven't had time to pursue them.
for our needs. Not for our customers though.
No complaints.
I rarely have any problems
Since I look at them only very occasionally, I am not sure I can interpret the logs of the nightly builds appropriately --- a guide to what to look for might be useful.
I seldom had problem migrating from one release to the next.
I've never had a problem with GHC producing erroneous results or crashing on me.
never had any misgivings, never been sorry for getting the latest version.
I've never met a show-stopping GHC bug.
There was painful GC bug in 6.2.1 though.
A bit harsh, but 6.4 has caused us trouble. Lava broke, for example. A bit awkward since I had just installed 6.4 on Mary's new lap-top for her, and she took Lava to demonstrate to Intel without checking that it would compile!
I was suprised to see that GHC 6.4 was released, and then see a bunch of bug reports against GHC 6.4. I think this is an indication that GHC needs more pre-release testing, by a more diverse set of users, than it is currently getting.
Yes, the release have been stable
I've only ever run across one bug myself
They seem to work
One more time: I'm not an expert, but at least GHC never crashed with the basic usage I need. Doesn't mean anything, I guess, but hey, that's cool ;)