New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to GHC 8.8.1 #8
Comments
This constitutes a special GHC 8.8.1/base-4.13 only compatibility release to support `MonadFail` The next non-micro-pointrelease will support a wider compat window again. Addresses #8
Thanks! May I ask why the new release supports ONLY ghc 8.8? https://matrix.hackage.haskell.org/#/package/haskell-src
(That seems not fully up-to-date, missing 8.8 and 8.6). Is this an oversight? Was the intention to put Line 39 in 9f473b6
I am asking since I have problem installing
The culprit seems to be that haskell-src-1.0.3.1 asks for I fail to understand why the released version on hackage differs from the current HEAD. (On the other hand, I am not a cabal expert.) |
@andreasabel The haskell-src-1.0.3.1 release has been done in this particular way deliberately and it's a pattern I've started for some time now; specifically I try to avoid nedlessly exploding the build-plan configuration space to avoid useless degrees of freedoms, especially if the new release has been done for the sole purpose and benefit of supporting a new major GHC version. I've meaning to document this recommended practice but never got around to it; it's very related to the concepts that underly the recommendations in https://github.com/haskell-infra/hackage-trustees/blob/master/cookbook.md#best-practice-for-managing-meta-data Also, you might notice that the haskell-src-1.0.3.1 release was done from the https://github.com/haskell-pkg-janitors/haskell-src/tree/1.0.3._ maintenance branch I created for this very purpose (also in case a future GHC release needs yet another release that can't be addressed by a simple meta-data update); that's why there is this apparent divergence w/ |
I have to say that this practice is rather intuition-breaking. If I stumbled upon https://hackage.haskell.org/package/haskell-src on Hackage, I would definitely make a mental note "okay, this package probably depends on latest GHC features or something so I can't use it, moving on". It would not occur to me that I should look at |
@neongreen sure, but why would you have two releases for the same minor version then? i.e. you have two releases that expose the very same API (otherwise they wouldn't be allowed to share the same minor API version), and by definition micro-releases are supposed to be a way to make internal changes not observable by API consumers which say depend on |
Sure, but "being creative" vs. "being boring and predictable" is a tradeoff – and I just wanted to give you an extra data point for balancing the tradeoff. For what it's worth, I also had no idea that Perhaps it would help if Hackage allowed prominently marking all "active" versions of a package when there is more than one. |
haskell-src
does not build with ghc 8.8.1:HTF depends on haskell-src, for instance.
The text was updated successfully, but these errors were encountered: