Roadmap for GHC 9.6 LTS / GHC 9.8 nightly ?

[andreasabel]

What would be the timeline to bump LTS to GHC 9.6 and nightly to GHC 9.8?
Do you want to await GHC 9.8.2? (But it does not have release plans yet, afaik.)

Currently, the GHC 9.4 LTS has still fewer packages than the 9.2 one, should that be addressed before closing 9.4?
(In this case, maybe maintainers should be alerted that the window for keeping their packages in LTS is closing...)

[alaendle]

Personally, I'm torn about it. From my perspective

• you hardly need another 9.4 lts - the package set got quite stable during the last weeks; it will also probably no longer give ghc 9.4.9 - so: compiler and package set could be considered stable
• I really would love a ghc 9.6 lts - since this would be a big step forward (at least for our projects) - mainly because of the newer compiler and the larger package set
• I have my doubts about the readiness of the ecosystem with regards to ghc-9.8 - so I think it is good advice to wait some weeks/months before moving nightly to 9.8.
• I wouldn't care about missing 9.4 packages - assuming that most users would switch to 9.6 anyway (which would provide the largest package set)

To summarize:

• If we only want to move LTS to 9.6 - I think we could do this in a timely manner (e.g. one more 9.4 lts and then move ahead to 9.6)
• If we follow the principle that ghc versions of LTS/nightly differ - I think we should wait (maybe a long time).

But that's just my perspective. Mainly thought from a user standpoint - what would be an improvement for our projects using stack.

[TeofilC]

FWIW I feel like the ecosystem often has a bit of a catch-22 with updating nightly to a new version of the compiler.

While there are some people updating packages as soon as bindists are released, I get the impression that most of the community waits for nightly to come out either because it signals stability of the compiler, because it alerts them to their package not building with the new compiler, or because they use stack and they need a resolver to test with.

At the same time, quite understandably, stackage waits for the ecosystem to catch up a bit before updating nightly.

I think the two of these interact to unnecessarily delay adoption of new compilers.

[Daniel-Diaz]

FWIW I feel like the ecosystem often has a bit of a catch-22 with updating nightly to a new version of the compiler.

While there are some people updating packages as soon as bindists are released, I get the impression that most of the community waits for nightly to come out either because it signals stability of the compiler, because it alerts them to their package not building with the new compiler, or because they use stack and they need a resolver to test with.

At the same time, quite understandably, stackage waits for the ecosystem to catch up a bit before updating nightly.

I think the two of these interact to unnecessarily delay adoption of new compilers.

This is exactly how I work. I have a nightly build of my own packages that checks them against the latest nightly snapshot. When any of these builds fail, I get a notification and I fix the broken package. I can't be the only one who checks their packages against the nightly snapshot.

[andreasabel]

Indeed, moving nightly to a new major GHC (or threatening to do so) will wake maintainers from their Sleeping Beauty slumber...

[ysangkok]

For the last three LTS'es, the release happened at least 100 days after the next GHC:

LTS major version	Y in X.Y.Z GHC version for .0 LTS	GHC version in .0 LTS	LTS release date for .0	Lag after first release of .1 release of next major GHC
15	.2	8.8.2	2020-02-16	37 days after 8.10.1
17	.3	8.10.3	2021-01-24	11 days before 9.0.1
19	.2	9.0.2	2022-03-17	139 days after 9.2.1
20	.5	9.2.5	2022-11-16	101 days after 9.4.1
21	.5	9.4.5	2023-06-20	102 days after 9.6.1
22	.3	9.6.3	2023-12-16	68 days after 9.8.1

GHC 9.8.1 was released on Oct 9. To continue the pattern Oct 9 + 100 days would be January 14, 2024.

[andreasabel]

11 days before 9.0.1

The old (written) policy was to make LTSs starting with .2 of the latest GHC (allowing it to stabilize a bit).

The new unwritten policy seems to be make LTSs for the next-to-latest GHC.
And nightly has somehow taken the role of the latest LTS, switching to the latest GHC once it has stabilized.

Maybe we need a new snapshot series, early, that tracks the latest GHC as soon as it gets out.
This would take the role of the previous nightly, reflecting the state of adoption of the latest GHC.

[alaendle]

Okay, I think we have some different understanding/expectation what stackage snapshots should provide. Since I fear that the discussion here might be biased towards the needs/wishes of package maintainers, I would like to add some (maybe controversial) points:

• Most important, we should aim to minimize effort for the people maintaining stackage
• For an industrial user mostly stability counts - and a package-set is only valuable if it covers "enough" packages
• And I would expect most industrial users use the latest LTS (because the ecosystem is up-to-date enough and breaking changes are seldom (thanks to following PVP)) - if needed some extra-deps are introduced via stack.yaml - but that may be my bubble.

The conclusions I draw from that can already be found in my previous #7186 (comment).

Also: I'm not sure if Stackage should server as a trigger for a dependency update. While understanding that some package maintainers work (or prefer) this way, I also fear that this workflow could lead to some cascading changes and therefore lot of churn (e.g. I couldn't update my packages since dependencies aren't GHC 9.8 ready, so my packages get disabled and I have now no control or a good notification system when I could/should update) - and I think in summary this causes lot of work for people maintaining packages with large dependency lists (since their packages will likely get dropped on every new LTS) and the maintainers of the package-set - filling out a lot of issues, getting lot of PR's, etc. - so I think "readiness" of the ecosystem is crucial before switching to a new GHC-version with nightly (you see that we've lost lot of packages from 9.2 to 9.4 even after months). I also know that this need to happen at some point in time - and the complete ecosystem is never fully prepared, but it should be in a reasonable proportion.

Maybe also a chance to advertise https://github.com/nomeata/haskell-bounds-bump-action.

And please don't get me wrong, I'm sure we all have the best intentions but look at things from different perspectives 👀.

[juhp]

I agree it is a balance, I would say we could/should probably release lts-22 by January at least.
We curators have briefly discussed whether we could maintain two lts's, though would allow us to be more
aggressive with nightly I feel and probably more realistic than adding an experimental stream.
But that requires some work on stackage-server and also ideally the lts workflow, which is highly manual currently.

(Wearing my Fedora hat I might really wish for a release this month since that would allow shipping ghc-9.6 in Fedora 40.)

[mihaimaruseac]

We now have a LTS-22

[juhp]

Thanks to @bergmark we also have the initial new nightly-style workflow now for lts-haskell