Skipping the GHC 9.8 LTS / GHC 9.10 Nightly #7462
Comments
|
Hmm, this has crossed my mind too, though it does feel quite unconventional... I do wish this would be formalized more by ghc versioning. |
|
Personally I tend to keep the current schema; so maybe just waiting for 9.6.6 (eta 2024-06-28 https://gitlab.haskell.org/ghc/ghc/-/milestones/401#tab-issues), create last lts-22, create lts-23 with ghc 9.8 and move nightly to ghc-9.10 feels more natural to me - and also means smaller steps (for us and potential stackage users that move from lts to lts). |
|
I'd like to defer the decision until after 9.6.6 is released. We certainly want to keep making lts-22 releases until that happens in order to pick up that ghc release. I'm still inclined to do lts-23 with ghc-9.8 and to delay the nightly switchover to 9.10 until after that begins. The de-prioritization of ghc-9.8 was not declared to be permanent, they are just temporarily prioritizing continued support of 9.6. They stated:
|
|
@ysangkok has flagged that Amazonka doesn't have a GHC 9.8-compatible release on Hackage. What's your timeframe on cutting 9.8 LTS? I don't really use Stack, but if we can get a 9.8-compatible release onto Hackage before LTS-23 snapshots start rolling out, that seems good for those that do. |
That's not the way I am reading it at all. The post outlines how 9.8 is only supported for the near future, not the long term. If 9.8 was supported for the long term, it wouldn't make sense to point out that it's supported for the "near future", this is a quote:
While they say that they'll focus on 9.8 because 9.6.6 is out, I am still getting the impression that after the upcoming 9.8 release, they'll go back to focusing on 9.6 again. This is also supported by the first sentence:
Note how they're not mentioning 9.8 there at all. I am getting the impression that the upcoming 9.8.3 release might be the last. |
|
I would say it is not certain that there will be a further release of 9.6 - well TBD I expect on an as-needed basis. (Though I admit I have heard it said that 9.8 is a weaker release than 9.10... Of course nobody is forced to adopt ghc-9.8 now: users can choose to stay on lts-22 longer if they so wish. @endgame bit hard to say right now: but I would hope ideally by this month or at least August. 🤞 |
|
It would be good to publish a TODO list for the GHC bump (9.8 LTS, 9.10 nightly) with a proposed deadline so that maintainers and stackage curators and volunteers would know what to prioritize. |
|
I think you are right @andreasabel - we don't yet have a good feeling for the state of the ecosystem wrt to ghc-9.10, I do feel it would be nice(r) to have the ghc-9.8.3 release first, but we don't know yet when that will happen. |
|
So, almost two months later, what's the take on a timeline for nightly 9.10 and/or LTS 9.8 now? |
|
@andreasabel I think we're waiting for 9.8.3, at least that's how I interpret Jens' last message. But it seems 9.8/9.10 currently are not being worked on, since the 9.12 fork is coming up on Sept 18th (scroll to the top of the page, note the chart shows the creation of issues for this milestone). After the 9.12 fork, and the release of 9.10.2, 9.8.3 is scheduled next, according to Zubin. Not sure why 9.12 wasn't covered in the blog post about release priorities. You can view the ghc 9.8 branch and the ghc 9.10 branch. They haven't seen commits for three months. |
maybe because that post is from May this year, about two weeks after 9.10.1 release? |
Ok, I thought they might have had a rough schedule for 9.12 at that time, but since it was so quickly after 9.10, it does make sense that they wouldn't have thought it'd influence the releases they mention.
Actually, I suppose this doesn't mean much, since apparently merge requests (MRs) are only merged when the release is being prepared. I suppose that means there is not really a 'current branch' for 9.8/9.10, you have to synthesize it from the MRs you think will go into the next release. |
I propose to go ahead with this now as no minor GHC releases are imminent. |
|
I have since changed my mind a little and now advocate waiting for a another new GHC release. I hope for GHC 9.8.3 (or 9.10.2 if necessary). Mainly because there is currently no GHC 9.8/9.10 release in which all packages are the same or newer than 9.6.6. So an upgrade would be a downgrade for some dependencies - which I would find strange. In addition, the 9.8 series has a number of open problems (https://gitlab.haskell.org/ghc/ghc/-/milestones/398#tab-issues), some of which are serious. All in all, not an ideal situation, and we will certainly never meet all of our users requirements, but it seems to me that the primary requirement for Stackage to provide a stable environment is currently best met in the 9.6 series. And believe me, I'm sorry to have to say this, because I'm really a fan of new features and generally latest bits 😿 |
Ah! I finally realize you're probably referring to boot packages (e.g. Cabal) here. It took me a while, because I was thinking of regular Hackage packages. But I agree, it does make sense to avoid a downgrade of boot libraries, especially since e.g. the Cabal bug relating to GHC plugins has been fixed since November 2023, so many have probably forgotten about the issue by now, if they ever knew about it. |
|
Judging from https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13319 and https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13320, I'd speculate that GHC 9.8.3 might be released in upcoming weeks. |
.2.3.2.5.5.3GHC 9.10.1 was released on 2024-05-10, which is already 45 days ago. Cabal-install-3.12, which is compatible, just got a release candidate.
Given that GHC devs decided to deprioritize GHC 9.8, I wonder if it makes sense to just skip the GHC 9.8 LTS, and move nightly to GHC 9.10? Then the GHC 9.6 LTS could be kept alive for longer.
The text was updated successfully, but these errors were encountered: