Release a hotfix for cabal-install-3.14

[phadej]

At this point it won't be hot, nor even warm, but at least fix.

Now with GHC-9.12.2 released, we need working cabal-install-3.14.

cabal-install-3.14.1.x is unusable on CI, but cabal-install-3.12 doesn't work with build-type: Custom packages.

[ulysses4ever]

cabal-install-3.14.1.x is unusable on CI

Why?

[phadej]

cabal-install-3.14.1.x is unusable on CI

Why?

#10704

and looks like others are running into that issue independently too. It's sad that issue was fixed very promptly, but it's been two months since: the fix is not released.

[ulysses4ever]

Thank you, that makes sense, @phadej . There were talks about another 3.14 release. The idea was, I think, to try to get several more fixes that are really close merged. @Kleidukos @Mikolaj ?

[phadej]

FWIW, the last time I asked that @mikolak answered

phadej and while we on this matter, any estimate of a date of next release of cabal-install-3.14? 
mikolaj plan ATM, in particular, because we have more unfixed than fixed regressions

and that was on Feburary 07. A month ago. As I look at https://github.com/haskell/cabal/issues?q=is%3Aissue%20label%3A%22regression%20in%203.14%22%20 there are still 5 open and just 4 closed issues now, so nothing really changed.

A release could have been done a month ago. Only one issue have been closed since (and only very recently, and it cannot be reproduced - so nothing had been really done for that).

Just make a release.

[Mikolaj]

Did you look closer? I had an impression a few more issues have PRs that fix them, but they are not merged yet.

[phadej]

but they are not merged yet.

I don't care. You could made a release a month ago, so you really should make one ASAP and not have people wait any longer. You can then make another release once more issues are fixed.

[mpickering]

I put up fixes for the remaining open issues in the 3.14 regression tag last week so I agree it would be a good time to do a new release.

[phadej]

In particular, GHC-9.12.2 had been released last week Friday, so now people are again hyped for GHC-9.12. But it's still not fully usable, because released cabal-install is buggy (i'd say essentially for most)

You could had anticipated the GHC-9.12.2 release and made a cabal-install last week; but hopefully I'm not asking for too much when I expect to see a cabal-install-3.14 release this week.

The GHC-9.12 + cabal-install-3.14 post release handling had been IMO very bad; major blocking issues but many months of wait time for fixes. GHC-9.14 is coming in July with prereleases already earlier.

As a library maintainer, I wish I could skip either (the rest of) GHC-9.12 or (all of) GHC-9.14 related upgrades; they just de-facto are too close.

[Mikolaj]

Come on, the last 3.14 cabal-install point release was only on 2025-01-05, two months and a bit ago. And, I'm afraid, the next minor release won't be ready in a week, since cabal releases take, roughly, a month on average, starting from backports and including manual QA and replacing crew members that went temporarily mad.

But fair enough, this indeed seems like a good moment. We decided during the meeting last Thursday to wait until all fixes are in and indeed only one waits for a review at this point, a couple need merging and a few require backports, so things are lining up.

Thank you for you kind interest in cabal and the user feedback you keep providing.

[Bodigrim]

And, I'm afraid, the next minor release won't be ready in a week, since cabal releases take, roghtly, a month on average, starting from backports and including manual QA and replacing crew members that went temporarily mad.

Resource constraints are understandable, but they put downstream maintainers in a very difficult position. Both @phadej and I have argued in the past that GHC release cadence is unsustainable. If even Cabal struggles to keep up, I don't really understand who is supposed to benefit from having a new GHC every 6 months.

As a library maintainer, I wish I could skip either (the rest of) GHC-9.12 or (all of) GHC-9.14 related upgrades; they just de-facto are too close.

Same here. I'm seriously considering to sit out GHC 9.14, if it comes as early as July.

[mpickering]

I do agree with the overall point that being more proactive with scheduling a release would have been helpful. I also agree with Oleg's point that waiting to do releases until "all bugs" have been fixed is not usually very useful, as more bugs are just reported in the interim period. Finally, I also agree it is a bit frustrating that there isn't a working cabal-install-3.14 yet for ghc-9.12.

However, I find the comments in this thread have quite a rude tone.

To my knowledge, no-one is directly paying for cabal-install releases, and the management is performed by volunteers. Therefore it is unreasonable in my opinion to make strongly worded suggestions to maintainers. There seems to be an implicit assumption that everyone must adhere to some unwritten standards.

Likewise, if there was a lot of demand for a new release, and there were people who were willing to help. I would find it unreasonable if the cabal maintainers didn't use the additional labour available to help with the process.

If you are contributing to a project in your free time then you are also free to set whatever boundaries you want about what contributions you make. You can decide to support whatever GHC versions you wish, support as many packages you wish and so on. No-one is forcing anyone to voluntary contribute to open-source software!

---

To take this topic back onto conversation. I think the status is

• There are MRs for all the reported regressions so far in 3.14
• There isn't a release date/period set for the point release.
• There isn't a release manager assigned for the release.
• It seems there is agreement amongst everyone to perform a new cabal-install release soon.

Does that sound right @Mikolaj ?

[Mikolaj]

I can confirm the regression list is finally under control and only a couple are not fixed (including regressions in 3.12, etc.) and they are not blockers, so apparently the approach of "waiting for fixes before a release" converges, after all. :)

Regarding the details of the release, let me defer to @Kleidukos, who is the release manager for the 3.14 series, but the cabal team is apparently ready and anticipating the release, as our public meeting notes and our public Matrix communication indicates.

[phadej]

To my knowledge, no-one is directly paying for cabal-install releases, and the management is performed by volunteers. Therefore it is unreasonable in my opinion to make strongly worded suggestions to maintainers. There seems to be an implicit assumption that everyone must adhere to some unwritten standards.

No-one is directly paying me to maintain the libraries I maintain either.

And there is unwritten standard for Haskell maintainers that support for new GHCs (or any dependencies for that matter) to be added (in a reasonable time frame) if a library or a tool is maintained at all.

If Cabal maintenance indeed doesn't get any funding from anywhere (anymore?), I find that very alarming. It feels wrong that some development (like Cabal-hooks) is clearly sponsored work, but the overall maintenance isn't.

..., since cabal releases take, roughly, a month on average,...

I find that alarming as well. Acceptable for a major, feature adding, "big" release. But we are talking about a bug fix release here.

[Mikolaj]

I don't think we should bury the actionable part of our discussion above with off-topics, but just to clarify and for full disclosure, as far as I'm aware, the bug-fixing part of maintenance was and is funded from short-term grants and contracts, e.g,. the hooks grant, as much as possible with full agreement from the funding providers. However, release management and similar long term tasks require stable long term funding, which regrettably does not exist. My own humble contributions are funded from various and changing sources, but the cabal maintainers' team was so far robust enough that if I vanished, it would operate fine, and I'd love to keep it that way, even though I have a reasonable hope I can keep contributing at this minimal scale for a very long time. Myself, as a user, I'd rather fund GHC more, since it could still absorb much more funding, it faces constant technical standards churn from the wider ecosystem and there's a lot of fantastic research that can be applied there or the application completed/improved.

[phadej]

My 5¢: new features in new GHC releases have no value if there are no tooling to use those GHC releases. From my point of view, GHC-9.12 is still not usable. The whole toolchain is not available.

[parsonsmatt]

Come on, the last 3.14 cabal-install point release was only on 2025-01-05, two months and a bit ago. And, I'm afraid, the next minor release won't be ready in a week, since cabal releases take, roughly, a month on average, starting from backports and including manual QA and replacing crew members that went temporarily mad.

I feel like 3 (or more) months is a long time to wait for a bugfix/patch release. The actual fix in #10704 was merged just 9 days after being reported, which is excellent turn around time.

Is the Cabal release infrastructure capable of doing really fast point releases for items like this? I can imagine wanting to roll up bugfixes to make fewer releases, but I wouldn't want to wait more than a few days (maybe a week) personally.

[Mikolaj]

@parsonsmatt: how did you arrive at 3 (or more) months?

[ffaf1]

Is the Cabal release infrastructure capable of doing really fast point releases for items like this?

No.

There has been excellent work by Hécate, Mikołaj et al. on streamlining releases, but the process is still definitely not cheap.

[hasufell]

Is the Cabal release infrastructure capable of doing really fast point releases for items like this?

No idea, but I can do that downstream in 1 day.

As such: I'm fine with backporting #10725 in GHCup. The patch seems simple enough.

[hasufell]

Done:

• https://github.com/stable-haskell/cabal/releases/tag/cabal-install-v3.14.1.1-p1
• https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/
• Cabal 3.14.1.1-p1 ghcup-metadata#294

@phadej can you test the binaries via:

ghcup -s https://raw.githubusercontent.com/haskell/ghcup-metadata/refs/heads/cabal-3.14.1.1-p1-proper/ghcup-0.0.9.yaml install cabal 3.14.1.1-p1

[phadej]

@hasufell, I cannot easily try it, but worse I cannot really use it even it works as 3.14.1.1-p1 is not an ordinary version (the -p1), and that would require some changes in setup, and I'm not willing to do them for (hopefully) one-off need.

I use https://hackage.haskell.org/package/Cabal-syntax-3.14.1.0/docs/Distribution-Version.html#t:Version to represent versions, and that one doesn't support "tags".

[hasufell]

@hasufell, I cannot easily try it, but worse I cannot really use it even it works as 3.14.1.1-p1 is not an ordinary version (the -p1), and that would require some changes in setup, and I'm not willing to do them for (hopefully) one-off need.

I use https://hackage.haskell.org/package/Cabal-syntax-3.14.1.0/docs/Distribution-Version.html#t:Version to represent versions, and that one doesn't support "tags".

haskell-CI code is your responsibility. Use a proper version library instead then: https://hackage.haskell.org/package/versions

[phadej]

responsibility?

Sorry, but that is too much.

[hasufell]

responsibility?

Sorry, but that is too much.

Why are you stressing maintainers and distributors then about your obscure use cases?

Edit: if you interface with GHCup, you SHOULD be able to deal with non-PVP versions.

[phadej]

you SHOULD be able to deal with non-PVP versions.

For GHC versions that's essentially impossible as you cannot say tested-with: GHC ==9.12.2-p1 (technically you can, but the tag will be dropped by the parser, with a warning). That's just how Cabal-syntax and thus haskell-ci works.

[hasufell]

you SHOULD be able to deal with non-PVP versions.

For GHC versions that's essentially impossible as you cannot say tested-with: GHC ==9.12.2-p1 (technically you can, but the tag will be dropped by the parser, with a warning). That's just how Cabal-syntax and thus haskell-ci works.

In haskell-CI, you could adjust the GHCup configuration manually like so:

GHCup config

url-source:
- GHCupURL
- ghcup-info:
    ghcupDownloads:
      Cabal:
        3.14.1.1:
          viTags:
            - Latest
          viChangeLog: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.14.1.1.md
          viArch:
            A_64:
              Linux_Debian:
                '(>= 10 && < 11)': &cabal-31411-p1-64-deb10
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-deb10.tar.xz
                  dlHash: 7676331281093258aa7beb6aae3f57b8c168f05cb04b898a4cfd9dfb166d0865
                '(>= 11 && < 12)': &cabal-31411-p1-64-deb11
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-deb11.tar.xz
                  dlHash: c2eec00deae19c0947970306066c7d7ff98b48ec789ecde897c12a067830175e
                '(>= 12 && < 13)': &cabal-31411-p1-64-deb12
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-deb12.tar.xz
                  dlHash: 1d3672404a1fce3f00ab502424cf930d67655e08905e22b0da23a66e5b423f1f
                unknown_versioning: *cabal-31411-p1-64-deb12
              Linux_Ubuntu:
                '( >= 20 && < 22 )': &cabal-31411-p1-64-ubuntu20
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-ubuntu20.04.tar.xz
                  dlHash: 856bdd40b5c2bfad745ffe7e7cde5f70a8a9379bbce2c07f2058775160e1d9f2
                '( >= 22 && < 24 )': &cabal-31411-p1-64-ubuntu22
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-ubuntu22.04.tar.xz
                  dlHash: ff26c607a62f7698477de8815d226790c80ed2b355229cc00afe6f21c8176f8e
                '( >= 24 && < 25 )': &cabal-31411-p1-64-ubuntu24
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-ubuntu24.04.tar.xz
                  dlHash: e04eb5f2ab380ef1b17f33cb4fe209fa629216b512641cebb2dbdcdf744350b7
                unknown_versioning: *cabal-31411-p1-64-ubuntu24
              Linux_Mint:
                '(>= 20 && < 21)': &cabal-31411-p1-64-mint20
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-mint20.tar.xz
                  dlHash: 27f7621e873da9d584776c2f439ae12f225f21b78a1534f88346ac5ac2e328ba
                '>= 21': &cabal-31411-p1-64-mint21
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-mint21.tar.xz
                  dlHash: 9fce5ee877f8d08a0d70087a7b33e45ff0183274e6ccddca406aff401ef97111
                unknown_versioning: *cabal-31411-p1-64-mint21
              Linux_Fedora:
                '(>= 33 && < 37)': &cabal-31411-p1-64-fedora33
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-fedora33.tar.xz
                  dlHash: f63cdc58a82d148726e924da21b7cd2e8a4f580a17ccaa8258214577396623ed
                '>= 37': &cabal-31411-p1-64-fedora37
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-fedora37.tar.xz
                  dlHash: b8900e710fb98227b29906202401377ef1e7873ba302c792efad733d9afc1e5a
                unknown_versioning: *cabal-31411-p1-64-fedora37
              Linux_Rocky:
                '( >= 8 && < 9 )': &cabal-31411-p1-64-rocky8
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-rocky8.tar.xz
                  dlHash: 9c8d01fa35c387468822cfd80938c02e1c6ec4f89bae9c12b75befb2128be954
                '( >= 9 )': &cabal-31411-p1-64-rocky9
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-rocky9.tar.xz
                  dlHash: ed7cb2f26c58bab1bd35652f649de1828c1f23a16d54fd128a05fa36c7ea2ce4
                unknown_versioning: *cabal-31411-p1-64-rocky9
              Linux_RedHat:
                unknown_versioning: *cabal-31411-p1-64-rocky8
              Linux_UnknownLinux:
                unknown_versioning: &cabal-31411-p1-64-unknown
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-unknown.tar.xz
                  dlHash: f3c20ccb693d46af31b97ddd4219577a9999e7b4d3053da7d22c3e9449273d27
              Linux_Alpine:
                '( >= 3.12 && < 3.19 )': &cabal-31411-p1-64-alpine312
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-alpine312.tar.xz
                  dlHash: 93766b3895337ba34b1a175f0eba1075eafb0a271d9c78d6bc4a09aac5b39602
                '( >= 3.19 )': &cabal-31411-p1-64-alpine319
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-linux-alpine319.tar.xz
                  dlHash: 51425c5bab0fe0308b72f9b61dc3bf943ae4ed1203ec3ab95231d25fa430df12
                unknown_versioning: *cabal-31411-p1-64-alpine319
              Linux_Void:
                unknown_versioning: *cabal-31411-p1-64-unknown
              Darwin:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-apple-darwin.tar.xz
                  dlHash: 360f0ae647efb771476ddb1693766237db4b3b48f9e17c6ea3e50b3478d1f34a
              Windows:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-mingw64.zip
                  dlHash: 616343c5188b4bc67e218c23b34da22dc874d7c17f01d955822302e53e0a8d1b
              FreeBSD:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-x86_64-portbld-freebsd.tar.xz
                  dlHash: 933ce144f9815e8526458910d3ef1b12d73438810ef1ace6fa7523a300b2362b
            A_32:
              Linux_UnknownLinux:
                unknown_versioning: &cabal-31411-p1-32-unknown
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-i386-linux-unknown.tar.xz
                  dlHash: 087e61335bcce764ac95fd06a073497fd6c58da025f20d0c79ae1d283f54f17e
              Linux_Alpine:
                unknown_versioning: *cabal-31411-p1-32-unknown
            A_ARM64:
              Linux_UnknownLinux:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-aarch64-linux-deb10.tar.xz
                  dlHash: df5b5567fb4b034a67e69f92ca66dacf34b156e6f70a8a475b005452e83022de
              Linux_Alpine:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-aarch64-linux-alpine.tar.xz
                  dlHash: 4edede2a20ee7b575d27d8ef22ce281d5163650b1049c4e709ced89ab8cbea2b
              Darwin:
                unknown_versioning:
                  dlUri: https://downloads.haskell.org/~ghcup/unofficial-bindists/cabal/3.14.1.1-p1/cabal-install-3.14.1.1-p1-aarch64-apple-darwin.tar.xz
                  dlHash: e75915b6508952b612900b1ac6d0ee11c828aaaad0cec1dafc1216b250ef33e5

This makes sense for CI, but not for regular end users, because they don't constantly start from an empty environment.

[parsonsmatt]

@hasufell I believe the ghcup patch should work great for folks using the haskell-actions/setup instead of haskell-CI. Thanks for putting it together!

[hasufell]

Otherwise cabal and GHCup could decide on a convention, e.g. where the 5th version component is reserved for distributors and will never be used by upstream.

[Mikolaj]

Otherwise cabal and GHCup could decide on a convention, e.g. where the 5th version component is reserved for distributors and will never be used by upstream.

I think it's safe to assume we won't ever use the 5th component.

[phadej]

@phadej can you test the binaries via:

https://github.com/haskell/aeson/actions/runs/14114216276/job/39540355736?pr=1134

Seems to work.

[Mikolaj]

Well done with the hotfix, I can see it in my ghcup tui! Anything else that needs to be done in this ticket?

BTW, the cabal team is proceeding with the 3.14.2 release that includes this fix (and a dozen others). If anybody would like to help with the release, e.g., review PRs that implement subsequent release steps (#10895 and #10894 at this point), please join us at https://matrix.to/#/#haskell:matrix.org.

[ulysses4ever]

3.14.2.0 has just been released. Should we close this issue?

https://discourse.haskell.org/t/cabal-install-3-14-2-0-released