I believe this seeming paradox can be resolved by the hypothesis that what both groups want is less busywork per unit time.
I suspect that the group that wants GHC to release faster thinks they will have less busywork if they can address breaking changes in smaller increments, and that the group that wants GHC to release slower thinks they will have less busywork if they can address more breaking changes in one go, to avoid frequent context switches.
The simplest way to please both groups is, I think, to cause less busywork by making fewer breaking changes.
The GHC team are also downstream of certain stakeholders: namely, the people and organizations that fund or directly contribute new features. I’m sure they don’t like waiting 6 months to get the thing they already worked for.
Indeed. The efforts to decouple GHC’s unstable internals from the Template Haskell API, GHC’s own API, and the base library seem like important work in that direction.
This is what nightlies and prereleases can deliver. It allows to merge features early, allows ghcup to distribute bindists for use of of those early adopters without compromising the experience of the larger Haskell community.
GHC development being affected by the fear of losing clients/funding seems like a precarious situation (if that is the case). I had hoped that the HF, as a middleman, would be able to alleviate such concerns.
I wouldn’t read too much into it. I’m just saying that, as a class, people who implement new features do exist. And if I was one of them, I’d definitely want to see those features in a stable release, so that I could actually use them in production.
This is an interesting conversation but I’m not sure what to take away from it.
Let us just remind ourselves: we all want the same thing, a Haskell ecosystem in which both upstream and downstream contributors feel valued and listened to, and in which friction is minimised. We may have different opinions about how to address that goal, especially with limited resources, but the more we talk to each other the more likely we are to build a healthy ecosystem.
With that in mind, here’s my summary:
Everyone wants less breakage. More precisely, (BG1): If a program compiles and works with GHC(X) then it should compile and work with GHC(X+1). This is the goal I express in this GHC stability state of play page. It is surprisingly difficult to acheve, for the reasons laid out there, but progress is being made on a number of fronts.
Library updates. Where we fail to achieve (BG1) we are stuck with the library-update problem. If you depend indirectly on package P, and package P needs some modification to compile with GHC(X+1), then you have to wait for all the package authors between you and P to update their packages before you can compile with GHC(X+1). That is why we have head.hackage for testing GHC; and it was the motivation behind the GHC.X.Hackage proposal. I understand the reasons for disliking GHC.X.Hackage; but I don’t know any other way to address the library-update problem, except by achieving (BG1).
I’m not sure what actions, if any, to take here.
Release schedule
Within a particular release, if we are forced to delay the schedule we should delay the entire remaining schedule, rather than compressing it to maintain artificial deadlines. E.g. if alpha-3 is delayed, we should delay RC1 too etc.
Perhaps we should rename alpha-3 as RC1, since many downstream users may not start work until they have a “release candidate”, for understandable reasons.
I’m not getting a strong signal in favour of more frequent releases, or less-frequent releases; just in favour of high-quality releases.
Does anyone else have actionable take-aways to suggest?
Does anyone else have actionable take-aways to suggest?
Sure, the nightly releases were quite promising to enable library maintainers (like me) to stay on top of the game and catch breaking changes and bugs on real-world codebases earlier. CI setups would greatly benefit from these, as well as people who wish to use experimental features that haven’t made it into a stable branch yet. The moment GHCHQ can vouch for nightly releases being produced and cared for, this will certainly greatly help with the trust in the periodical releases.
I’m in favor of more minor releases and less major releases, so that there are less GHC branches to maintain and the ones that are there will have a longer shelf life, allowing for more backports (not just of bugfixes, but also performance improvements and other things).
At the moment, I can barely update my own code bases to 9.6.x (lots of small problems)… and GHC HQ is already in the process of pushing out 9.10. I don’t see how I can keep this up, honestly. GHCup still recommends 9.4.8, but it’s effectively already abandoned by GHC HQ: GHC Status · Wiki · Glasgow Haskell Compiler / GHC · GitLab
Other alternatives were discussed previously, but I don’t remember all the arguments against it… I don’t have a lot of visibility on the pain points and cost centers of GHC maintenance:
GHC LTS releases (long-running branches)
rust model: very conservative stable releases, fast iterating nightlies (this might effectively be like maintaining two compilers)
language editions (so that I can opt out of all breaking changes, even with newer compilers)
So I won’t put forward an opinion on whether any of those are feasible.
As it stands, nightlies require robust architecture and persistent storage to be usable and that may be an unnecessary time sink for GHC HQ. However, I don’t know if I will have time for that this year either.
I guess I would like to get to point where basically current ghc9 would correspond to Stackage LTS and ghc10 to Nightly.
Well I guess forward-looking I really mean: ghc10 would be stable (ie the same Stackage LTS major version could use GHC 10.1, 10.2, 10.3, 10.4,… minor versions). Whereas GHC nightly might live in Stackage “experimental” (nightly) say.
This would require a complete change of versioning and releases of course. New features could be gradually backported as needed/desired to stable releases if they don’t break stable GHC.
In the ideal stable world, ghc10 would then be the last final stable major version of GHC (à la rust 1) ever.
Nightlies as they they were promised to exist have been consistently available for the last 6 months. (see here).
I don’t think it’s very helpful language to label them as a “failure”. It’s more of a difference in opinion between @hasufell and GHC developers about the level of resources to invest in their production. There doesn’t seem to have been very much uptake in using nightlies so it is difficult to justify further investment in improving the infrastructure around them.
This design document from the HF talks about indefinite bindist retention and predictable URLs in the requirements section. Neither of that is the case at the moment.
As I repeatedly explained to you privately Julian, the nightlies were only ever promised to be provided on a best-effort basis by exposing what already existed as part of nightly pipelines to users. The document you link clearly says at the top that it’s not the final plan. The expectations about availability are documented on the GHC Wiki.
In retrospect it seems that it would have been much better to not engage with this project at all.
Thank you for this build, I suppose it should be used with cabal-install-3.12 prerelease which supports js-sources. It seems like I can find a build plan for miso using the following command line for the sample-app (from inside the miso repo).
It does seem like “latest” is not correct, since the GHC build is for a specific version of Emscripten, and not the latest.
