search

haskell / containers

Assorted concrete container types
https://hackage.haskell.org/package/containers
314 stars 177 forks source link

Release for GHC 9.8.1 #971

Closed bgamari closed 9 months ago

bgamari commented 10 months ago

@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 f61b0c9104a3c436361f56a0974c5eeef40c1b89).

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 commented 10 months ago

Yes, we can make a release this week.

treeowl commented 9 months ago

I'll be able to make the release tomorrow.

treeowl commented 9 months ago

Released!

Bodigrim commented 9 months ago

@treeowl something seems wrong here: f5d0b13251291c3bd1ae396f3e6c8b0b9eaf58b0 says "Bump version to 0.7", but actually bumps to 0.6.8 only: https://github.com/haskell/containers/blob/f5d0b13251291c3bd1ae396f3e6c8b0b9eaf58b0/containers/containers.cabal#L1-L2

Hackage release seems correct however.

treeowl commented 9 months ago

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

bgamari commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

I raised https://github.com/haskell/cabal/issues/9289 for Cabal, CC @Kleidukos.

bgamari commented 9 months ago

@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 commented 9 months ago

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 commented 9 months ago

@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 8663795322622ac77cc78566185bffbc84e299f2 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 commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

Thank you.

treeowl commented 9 months ago

@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 commented 9 months ago

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

bgamari commented 9 months ago

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