Hi everyone, I opened a GHC Proposal to improve the release cycle of GHC and its integration in the Haskell ecosystem. You can read it here.
7 Likes
As a hobbyist myself, I would really not like it if the “preview” would not be immediately available for me to tinker with, even if almost no libraries support it.
I think another alternative would be to always call the x.y.1 release of GHC a “beta” or “preview” release. So it would still be released publicly, just under a different name.
I think many x.y.1 releases have had critical bugs and therefore should already be avoided by the general user base. This would also give time to maintainers to update their library to this new version. Historically, I would say the average time between the x.y.1 and x.y.2 releases is about 6 months, which is admittedly a bit long.
Hi jaror,
As a hobbyist myself, I would really not like it if the “preview” would not be immediately available for me to tinker with, even if almost no libraries support it.
Could you please explain how making this “preview” available on ghcup and the Ubuntu PPA would prevent you from tinkering with it?
2 Likes
Oh sorry, I must have misunderstood. So my proposal would then be to always make the x.y.1 releases a preview release and have a non-fixed time window which is until the x.y.2 release.
The aim is to give library and tooling authors the means to update their code to accomodate the new version, without publishing a user-oriented GHC release yet. The kind of release that is proposed is in itself no different from a traditional Release Candidate. This proposal aims at polishing the surrounding release cycle and schedule.
This is really sensible!
I suggest that we implement the following strategy: Once we arrive at a final RC of the next GHC version, we publish a “Maintainer Preview” version, make it available in ghcup, the Ubuntu PPA (so that it can be easily used by CI systems like GitHub Actions or Travis), and send a call to maintainers that (in substance) say:
It would be nice to leverage build automation here - If a RC is made available, building packages in stackage/hackage could be triggered. Messages for packages that fail to build could then be more precisely sent out or swarmed by support.
Taken from my direct experience as a technical writer for GHC, I can testify many people have the potential to meaningfully contribute to GHC and Haskell in other roles than compiler engineer or systems programmers. I think the plan laid out in this proposal would open an interesting gateway for many people to be involved in our communities to fullfil community-facing roles.
I’d agree, and this is a great way to mentor and pass on knowledge/skills for those who participate in sorting out updates!
4 Likes