Messaging on FAQ for New GHC release timing

[JulianLeviston]

I realise this is early, and it's in no way a criticism at all.

However, I found myself wondering when 8.10.1 will be added to nightly and LTS. So, I'm curious if we could possibly adjust the FAQ so it sets expectation (or some other signaling) for when these things generally might happen with respect to GHC release dates.

Thank you for such excellent tooling!

[mouse07410]

Let me second this request, please. We very much need a 8.10.1-capable resolver.

[svenpanne]

Just a ping: GHC 8.10.1 ist out for half a year now, and the next release is probably coming soon. So the question is: What ist holding up an LTS release with it? If you just look at the number of packages in the LTS for 8.8.4 and the nightly for 8.10.2, there is only a difference of 15, so this is probably not the reason. Or are some crucial packages still missing?

Put another way: It is basically impossible to see how one could help with getting an LTS for 8.10 out of the door. I am sure this information is somewhere, but I'm unable to find it. Is there a link/meta-issue/tag for this? Perhaps putting this kind of information prominently on the stackage.org pages might help to reduce the huge lag of stackage behind the GHC releases.

[DanBurton]

GHC 8.10.3 will be out soon, and the next major LTS bump will likely follow shortly after.

There is a known issue on windows with ghc 8.10.2: https://www.stackage.org/blog/2020/08/ghc-8-10-2-windows-workaround

[AlistairB]

Just to chime in that visibility into the LTS major release process (and I suppose nightly moving to new GHC versions as well) would be great. I suppose the simplest solution would be to move the discussion around this into some public place ie. a github issue so others can follow along and plan accordingly.

Currently I obsessively monitor this repo to try and get an inkling ;) I'm assuming the new plan is to wait for 8.10.4 re moving lts to 8.10.

[svenpanne]

Moving this discussion to a more prominent place would indeed be a good idea. IMHO there is something fundamentally wrong when the LTS is lagging 10 months (at least) behind the GHC release. I am not sure if this is an organizational, technical or manpower problem, so an open discussion would be very beneficial. There are probably people willing to help, but they would need to know what to do...

[mihaimaruseac]

I'll try to cut a new LTS over the long weekend.

[mihaimaruseac]

We finally published LTS 17 for GHC 8.10.3

[juhp]

I feel it is a good general ecosystem topic for HF actually.

[and-pete]

Hello! :) Did this thread result in any doc updates for setting expectations around the lag in reflecting a compiler release. The README mentions:

The lag for minor ghc releases should be less but it still requires extra work and there is usually some delay - this also allows for some community testing before updating LTS.

That was for the LTS release though. What would be the timeframe for something like the nightly build's current compiler version of 8.10.4 bumped to the recent 8.10.5 point release? Thanks in advance! :)

[juhp]

Nightly just moved to ghc-9.0.1.

But we plan to move lts18 to 8.10.6 after it is released - 8.10.5 has a regression affecting doctests.

[JulianLeviston]

While it seems like the messaging is much clearer now than when I originally opened this issue, the core issue remains that it's a bit opaque for people curious about when certain versions of GHC will land and what might be holding it up (and also if anything can be done to help).

I suppose this is inevitable, but perhaps we could, for each release not yet supported by Stackage, as it gets cut, link to a general detailed status issue on Stackage to do with which issues are holding specific new versions of GHC back from making it into Stackage, perhaps directly from the FAQ? That's of course assuming such issues exist.

I don't know, really. This is only a thought I just had when reviewing this issue now. I don't really want to make more work for other people :(

[juhp]

I think it is a good idea to have a ticket to track the next major ghc version once it is released.
We could also think about defining criteria for moving Nightly to the next major version:
eg should it be more package- or time-based. There is a balance here between having
a useful resolver and early exposure to users (ie bleeding edge vs stability).

[demming]

As Adam referred me to this discussion from the issue I raised (linked just above), I'd like to offer an additional perspective. I see Jens' note above mentioning that 8.10.5 will be skipped for 8.10.6 in the 18th LTS branch. As of now, 8.10.5 is the first and so far only release that actually works on aarch64 M1 Macs. With the current GHC release setup provided by Stackage, a Mac user on an M1 chipset can't really use stack. How severe is that doctest regression? Is it the only reason to forego 8.10.5? Does it weigh so heavily against the M1 support? Is there any other way to at least transitorily introduce 8.10.5 without affecting doctest users (like me)?

I see there are currently three issues remaining unresolved in the GHC 8.10.6 milestone, which I suppose might take a month or so at least, especially the Darwin x86_64 issue seems rather involved.

As for the subject matter, I for my part would most surely appreciate a kind of a roadmap, perhaps automatically generated from CI output for the released GHC versions, so as to better plan ahead and control for backwards compatibility. This would also provide suggestions for version pinning. A ticket tracker is also a great approach I think. There is an apparent distinction in the resources required, however: in the former case they would have to be consumed primarily outright, in advance, which would hopefully pay off in the long run, whereas in the latter more manual work is required in the long run. If resources permit, the tracking ticket could be generated directly from CI output.

As for me, in general, I rarely need the most recent GHC release, for I have a preference for stability and reliability, but sometimes, like in this case, critical issues are resolved upstream and it becomes of utmost importance to be enabled to use it. I think this is quite a common situation.

[juhp]

@demming you should be able to override the ghc version in stack.yaml adding compiler: ghc-8.10.5.
https://docs.haskellstack.org/en/stable/yaml_configuration/#compiler

[demming]

@juhp Indeed, thank you, apparently I completely missed that option, I gladly stand corrected. However, without a vetted snapshot any incompatibility risk is then on me. That's fair enough, given the exposure to the doctest regression. Guess I just got used to the comfort of the usually seamless build management with stack. Thanks again, greatly appreciated!

[mouse07410]

@juhp but without the curated set of packages, what's the advantage/benefit of using resolver ghc-8.10.5, compared to just building with cabal?

[juhp]

@mouse07410 not resolver: ghc-8.10.5...
compiler is a different field that overrides the resolver's compiler.

[asr]

But we plan to move lts18 to 8.10.6 after it is released - 8.10.5 has a regression affecting doctests.

Please note that GHC 8.10.6 was released.

[juhp]

See also commercialhaskell/lts-haskell#324

[juhp]

(@snoyberg pushed https://www.stackage.org/lts-18.7)