Test against GHC 9.12.4-rc1

[wz1000]

Hi, we have just published GHC 9.12.4-rc1.

9.12.3 had an unfortunate bug that was discovered by the stackage maintainers when testing the GHC 9.12 stackage nightly.

I discussed with @juhp and think it would be a good idea to include some sort of validation step against stackage as part of the RC process if it is easy to do.

In the medium/long term, I think it would be beneficial to have some way for the GHC release manager to be able to build and test minor releases against a stackage snapshot themselves, whether by using the existing stackage infrastructure or by building an alternative infrastructure that can consume the metadata and build/run the tests.

However, for now, it seems like it would be quite helpful to at least start validating RCs against stackage, if it is feasible for stackage maintainers to help with this.

[juhp]

Noting:

filepath-1.5.5.0 (changelog) is out of bounds for:

• filepath-bytestring-1.5.2.0.3 (>=1.4.100.4 && < 1.5.0.0 || >=1.5.2.0 && < =1.5.4.0). Lukas Epple sternenseemann@systemli.org @sternenseemann. Used by: library

transformers-0.6.3.0 (changelog) is out of bounds for:

• web-rep-0.14.0.1 (>=0.5.6 && < 0.6.2). Tony Day tonyday567@gmail.com @tonyday567. Used by: library
• xdg-desktop-entry-0.1.1.3 (>=0.5.6 && < 0.6.2). Ivan Malison IvanMalison@gmail.com @IvanMalison. Used by: library

[fishtreesugar]

@colonelpanic8

[colonelpanic8]

What exactly is the issue?

[fishtreesugar]

@colonelpanic8 GHC 9.12.4 bumped transformers to 0.6.3.0, while xdg-desktop-entry restricts it to >=0.5.6 && <0.6.2, so the upper bound needs to be relaxed.

[sternenseemann]

• filepath-bytestring-1.5.2.0.3 (>=1.4.100.4 && < 1.5.0.0 || >=1.5.2.0 && < =1.5.4.0). Lukas Epple sternenseemann@systemli.org @sternenseemann. Used by: library

I've submitted a patch revising the bounds to Joey. Could also be resolved by a Hackage Revision allowing <= 1.5.5.0, no code changes necessary.

[colonelpanic8]

Released xdg-desktop-entry-0.1.1.4 to Hackage with a relaxed transformers bound (< 0.7), and updated the package to live under the taffybar monorepo. Hackage: https://hackage.haskell.org/package/xdg-desktop-entry-0.1.1.4

[juhp]

• filepath-bytestring-1.5.2.0.3 (>=1.4.100.4 && < 1.5.0.0 || >=1.5.2.0 && < =1.5.4.0). Lukas Epple sternenseemann@systemli.org @sternenseemann. Used by: library

I've submitted a patch revising the bounds to Joey. Could also be resolved by a Hackage Revision allowing <= 1.5.5.0, no code changes necessary.

Thanks - though the < =1.5.4.0 bound is highly suspicious I feel
(not to mention the gap in the < = :palmface: How does that even parse ;-))

[juhp]

I wasn't smart enough to persuade stack setup to install the RC1 without a stack.yaml file, so I just installed the ubuntu bindist manually by hand.

• isocline-1.0.9's test-example seemed to hang

but I can't really say for sure or know if this a regression:
the testsuite has been failable in nightly for a long time.
It shouldn't hard to check this though.

Otherwise no problems encountered as far as I can tell.

So it seems promising from the stackage perspective
Though we won't publish this snapshot - I really not sure publishing would work anyway.

But people who want to test RC1 with stack should be able to override nightly to use RC1.

[juhp]

* isocline-1.0.9's `test-example` seemed to hang

but I can't really say for sure or know if this a regression: the testsuite has been failable in nightly for a long time. It shouldn't hard to check this though.

I can run it manually fine - actually both the 9.12.3 build and the RC1 build.

We should probably exclude it since it is interactive and so hangs. (edit: done)

[sternenseemann]

Thanks - though the < =1.5.4.0 bound is highly suspicious I feel
(not to mention the gap in the < = :palmface: How does that even parse ;-))

filepath-bytestring aims to exactly replicate the behavior of filepath and the constraint basically tracks this (I'm not sure this is the best way, but what the hell). Specifically, filepath-bytestring doesn't want to claim it behaves as filepath does when a minor version bump fixes some edge case etc. Nowadays, filepath-bytestring has quite wide constraints since most changes no longer affect the old System.FilePath API. (The gap in the constraints exists because filepath 1.5.0.0 was quickly deprecated due to some issue iirc and there never was a filepath-bytestring version that behaved the same.)

In any case, filepath-bytestring will eventually disappear. I still need to move my package off it (which I never get around to). git-annex still needs it for Setup.hs, but I assume Joey will change this eventually as well.

[juhp]

(Sure I am not that worried about filepath-bytestring - just raised my eyebrows.
The comment about the gap was about whitespace, not versions, haha.
Also in my interpretation of PVP, libraries should not change user observable behaviour with the fourth component of version, but anyway... We are getting fairly OT and into the weeds, so sorry for bringing it up here.)