Release for GHC 9.8.1

[bgamari]

@treeowl, on reviewing GHC's submodules I noticed that the containers commit used by GHC 9.8.1 has a few substantive changes relative to the most recent release, 0.6.7. Unfortunately, this means that a Hackage revision will not be sufficient and we will instead need a proper release. Do you suppose this could happen sometime in the next week or so?

If a release is not possible then I can instead bump GHC back to 0.6.7 with a bounds bump revision (namely f61b0c9).

Apologies for noticing this so late; my earlier audit from our discussion in #955 left me thinking that the only changes were in benchmarks and tests.

[treeowl]

Yes, we can make a release this week.

[treeowl]

I'll be able to make the release tomorrow.

[treeowl]

Released!

[Bodigrim]

@treeowl something seems wrong here: f5d0b13 says "Bump version to 0.7", but actually bumps to 0.6.8 only:

containers/containers/containers.cabal

Lines 1 to 2 in f5d0b13

	name: containers
	version: 0.6.8

Hackage release seems correct however.

[treeowl]

Yes, that commit is broken. The next one fixes it, no?

[bgamari]

I should have noticed this mix-up this morning. I had assumed that the master commit was the final release; in hindsight I should have noticed that something was amiss when I noticed that there was no tag uploaded. @treeowl, if there is a next commit then I'm afraid it wasn't pushed.

Unfortunately, the GHC release pipeline which I had planned to cut today's release candidate from refers to this broken commit and will need to be scrapped. This implies that we will need to push the release candidate by at least a day. However, I fear that the situation is even worse than this as none of the boot libraries' bounds current accommodate containers-0.7. Fixing this would very likely take weeks.

@treeowl, I don't believe a major release of containers is feasible at this juncture. At this point I think we should plan to do the bare minimum to get the GHC release out the door. I believe the only thing preventing us from using 0.6.7 is the deepseq < 1.5 constraint. Would you be willing to lift this in a revision?

[Bodigrim]

However, I fear that the situation is even worse than this as none of the boot libraries' bounds current accommodate containers-0.7. Fixing this would very likely take weeks.

@bgamari FWIW I think it's only Cabal / Cabal-syntax who needs a bump for containers, and Cabal-3.10.2.0 is pending a release anyway, might as well do it.

Uh, haskeline also needs a bump, but that's easy, the package is under your control.

...and hpc / libiserv, but that's not too bad, I think both are within GHC team reach?..

[Bodigrim]

I raised haskell/cabal#9289 for Cabal, CC @Kleidukos.

[bgamari]

@Bodigrim beyond the problem of boot library bounds, there is also the matter of other downstream users. Ideally we try not to bump major versions this late in the cycle since downstreams may have already started bumping their bounds to accommodate the new release.

[treeowl]

There is a change in Data.Graph that is at least theoretically breaking. I believe that was submitted by @Bodigrim . So either we can say that we are confident that won't actually break anything and call this minor, or we can back that out till next release. I don't remember the reason for the deepseq bump off the top of my head, and I can't look right now.

[bgamari]

@treeowl, the deepseq bounds bump is necessary because GHC 9.8 will ship with deepseq-1.5.

My proposal is that we simply create a containers-0.6 branch, cherry-pick 8663795 to it, and push a Hackage revision with this bump. To me, this seems like the lowest-risk approach, which is my strong preference at this late stage of the release cycle.

[Bodigrim]

There is a change in Data.Graph that is at least theoretically breaking. I believe that was submitted by @Bodigrim . So either we can say that we are confident that won't actually break anything and call this minor, or we can back that out till next release.

I don't believe the change #953 can break anything in compile time, but I classified it as breaking back then because instance {Show,Read} (SCC vertex) is now different. E. g., golden tests comparing serialised SCC will get broken.

[treeowl]

@bgamari , most of the release is documentation and testing improvements, so I think just backing out the SCC change from 0.7 will produce a good 0.6. I'll have to look after my rehearsal.

[bgamari]

Thank you.

[treeowl]

@bgamari I backed out the potentially breaking commit on an 0.6.8 branch. I don't think any of the other changes could plausibly break anything.

[bgamari]

Will you be able to cut a release from this branch?

[bgamari]

Ahh , I see that you have already done so. Thanks for the fast turnaround. @treeowl .