Please revise GHC release policy

Links
1

I posted this on the GHC tracker, but giving a link here for more visibility: #26067: Please revise the release policy · Issues · Glasgow Haskell Compiler / GHC · GitLab

Basically, it looks to me that the current release policy serves no one (developers have to spend tons of time backporting bugfixes to multiple branches, while users are getting confused about which recent major release to pick, while these releases can lag behind HEAD wrt. bugfixes for a long time) and revising it to have less major version releases and more minor (bugfix) releases would be a substantial improvement.

9 Likes
2

Doesn’t this hold up new extensions and features? This feels like a change purely from a maintainer/stability advocate standpoint.

Not saying anything about the current process (I am pretty apathetic to it atm).

Maybe we need an ongoing stable major version and unstable major version. The unstable one accumulates new stuff (without considering compat - it’s unstable) until it crystallizes into the next stable version on some schedule. You release what you have, more or less.

Maybe that’s how it already works but faster?

3

Doesn’t this hold up new extensions and features?

Those new extensions and features may as well not exist if the system that provides them is about as stable as quicksand.

Innovation relies on stability:

  • just as ship-building relies on the stability of dry docks (or other land-based infrastructure), or sheltered harbours (in the case of mobile/floating dry docks).

  • or tall buildings in cities, where each new floor is constructed when the current (top) floor is sufficiently stable.

As for software, it’s so much easier to “innovative” when all of the dependencies have been stabilised. So yes:

  • this is a change from a maintainer/stability advocate standpoint,

  • but those who “innovate” will also benefit from it.

2 Likes
4

For experimental purposes, maybe, but not for proper use… given that many people these days seem to skip one or two releases anyway before they upgrade their codebases.

For those experimental purposes, there are other solutions (such as nightlies).

4 Likes
5

doing the painful thing less frequently doesn’t improve stability. we should be asking “why is it painful? how can we improve those things?” deferring the pain makes it worse, not better – you’re taking on a larger change, after all.

8 Likes
6

Every release, even if minor, requires attention from the whole ecosystem:

  • GHCup
  • Stack/Stackage
  • Cabal (it’s intertwined with GHC)
  • HLS
  • Library developers and hackage trustees (upper bounds, breaking changes, etc)
  • application developers

In addition, we have significant mental/decision overhead now regarding the question “which GHC branch should I pick?”.

Less frequent major releases remove some of the work for library/application developers and requires less work for HLS to adapt to the otherwise constantly changing GHC API. But for distributors, it makes little difference: my work load is almost the same, no matter if it’s a minor or major release. Stackage certainly has it a bit easier on minor updates, though.

My hope is that less frequent major releases also positively impact the release quality and as such there’s also less need for constant minor updates. I’m not sure if that’s realistic.

I just wanted to point out that 3 breaking changes distributed over 3 releases still requires more work/attention than 3 breaking changes in one release.

7 Likes
7

Moreover, the problem here isn’t “pain”, but “context switches” - it takes the average human brain almost half an hour to re-establish it’s concentration on a task after being interrupted. So dealing with lots of small breaking changes costs more in mental effort than a few large changes.

2 Likes
8

…or just providing regular (compressed) snapshots of GHC’s “cutting edge” sources: experimenters can then test the build system as well as the compiler.

1 Like
9

I think this is a valid point, but incompatible with your suggestion that people should use nightlies instead of having 6-monthly releases.

For nightlies to be usable, they should have support from the ecosystem including the things you list.

Currently that is rarely the case.

So if we wanted to switch to a model where we have fewer major releases but nightlies were a viable option that would increase the amount of work necessary as the ecosystem would continually have to keep up with nightlies.

That is not to say we shouldn’t use nightlies more. I think we should but it will take work.

4 Likes
10

I beg to differ. But I was a bit handwavy.

First, nightlies have to be supported properly in GHCup, second we need a way to opt out of breaking changes of the latest compilers. There are multiple attempts at doing that, such as base split and language editions.

So you would get access to experimental compiler features right after they have been merged and may use it on parts of the ecosystem. But you don’t get guarantees that those experimental features will make it in that shape (or at all) into a proper release.

3 Likes
11

If only we did have Rust-style (language) editions (as opposed to whatever this was supposed to be)…but we don’t. However I think the breakup of base is still going.

12

I think things like that will make both new nightlies and major releases less work to support for the ecosystem, and that would be great!

HLS for instance depends quite a bit on the GHC API and I’m a bit sceptical we will ever get to a stage where it won’t often break with nightlies. ghcide is included in head.hackage and it breaks pretty often.

1 Like
13

I agree with the filed issue, however some kind of design needs to be carefully hashed out.
It is not that easy, but surely we can come up with something better than the status quo.

Thinking in terms of Stackage a maximum of 2 stable maintained major releases should be sufficient I reckon. Ideally I would prefer to see just one stable major version, but that feels so far from where we are currently that it is probably not realistic in the short time.

An idea: something like do a major stable release each year ahead of Zurihac and an unstable major alpha/beta pre-release before ICFP (or vice versa?). In between there could be alternating bimonthly or quarterly minor releases or something like that. The sequence of quarterly RC’s would then culminate in the stable major release the following year.

I have even been pondering whether we could add an experimental channel (stream) to Stackage (ahead of nightly): ie currently that would be 9.12, before it moves to nightly.

2 Likes
14

doing the painful thing less frequently doesn’t improve stability. we should be asking “why is it painful? how can we improve those things?” deferring the pain makes it worse, not better – you’re taking on a larger change, after all.

I strongly agree with this. Slowing down seems unlikely to help. I think there are quite a selection of different problems depending who you are, and the remedy may be different. @hasufell has a good list.

GHCUp/Stack/Stackage/Cabal/HLS

Mostly per-release busy-work where it doesn’t matter so much whether it’s a major or minor one. Sometimes tricky code changes, but indeed perhaps better to front-load these. HLS has a lot of dependencies, so it’s also has some of the “library developer” problems.

Library developers and hackage trustees (upper bounds, breaking changes, etc)

My belief is that almost all of this is about library changes, not changes to GHC the compiler. So the thing I’m excited about here is the ongoing work to decouple the version of base (and template-haskell) from GHC.

application developers

Here I think the question is mostly “do my dependencies work?” (previous point), and “is the compiler buggy?”. The fact that a lot of the major compiler versions are buggy is definitely a problem. Here I do think we could benefit from having LTS compiler versions. Empirically, it seems to take a while to find all the bugs and backport fixes: LTS versions give time for that process to happen. It’s not just us - it’s true for the Linux kernel as well!

This might also help with the amount of release work for GHC devs. If people mostly care about backports to the LTS branch, perhaps you can get away with having fewer active releases.

In addition, we have significant mental/decision overhead now regarding the question “which GHC branch should I pick?”.

Again, a LTS compiler would help with this.

Perhaps “frequent releases + LTS” is in practice similar to “infrequent releases + nightlies”. Personally I think the former is a bit easier to understand.

9 Likes
15

My feeling is that there are often bugs in new versions of GHC that only turn up when GHC gets tested against large codebases or a large percentage of the ecosystem. We need to find, fix and release fixes for these bugs before a version of GHC can become “stable”.

Yet, I think often users are unwilling to upgrade until a version becomes “stable”. And so the discovery of bugs is delayed.

I can imagine a longer support window making this situation worse if we aren’t careful.

4 Likes
16

shrug Definitely would help me and other people in the thread. First bring release cadence in line with community resources, then figure out and implement whatever “stability” improvements you want, then ask unpaid volunteers maintaining vital parts of infrastructure if they would like to increase cadence. Not vice versa.

5 Likes
17

I think it would be helpful to understand which parts of the post-release workflow explained in a previous discussion of this topic are not amenable to automation in principle, and which are amenable in practice but haven’t been due to some blocker. We might find some things we can work on to improve the situation.

Alternatively, we might be able to take the low-tech solution of finding more volunteers to help.

2 Likes
18

I’m afraid that’s a far more ambitious enterprise than just reducing release cadence.

And even if we managed to drive some hackage based reverse-dep builder that doesn’t blow up in infrastructure cost, that would still only be semi-automatic, because you definitely don’t want to bump dependency bounds without the maintainers final approval.

19

…which one? There are now so many to choose from, including this one:

Remember:

…funding has been reduced (hence chreekat’s loss of full-time employment).

20

I have no doubt that the people at the sharp end of dealing with releases, @hasufell, @bodigrim etc. are experiencing real problems that cause them real work. I’m not involved in that work, so I don’t have a clear idea what it entails, so what I say on this matter is not tailored to the precise reality of the situation.

However, I cannot believe that a quarter of the way into the 21st century, using the world’s most advanced language in common usage, that there isn’t a way of automating the release process that would cut the manual work dramatically, and allow us to comfortably do two releases a year.

Disclaimers:

I am not saying that people like @hasufell, @bodigrim etc. who are already burdened with this work should take on more work.

I am aware that CI and release management is big business in any firm with a software team, so I am not expecting my suggestion to be easy or cheap to implement.

1 Like