Haskell CI for GHC 8.0 - 9.10; allow mtl-2.3

[andreasabel]

This adds a CI generated by (my fork of) haskell-ci.
Also: fix building with mtl-2.3

@int-e : Could I get a Hackage release of this fix?

[andreasabel]

@int-e P.S.: CI ran on my fork and will run here once this PR is merged into master: https://github.com/andreasabel/union-find-array/actions/runs/8875147020

[int-e]

Hi, I've cherry-picked the changes that bump the mtl version and published a new version 0.1.0.4 on hackage.

I'm less enthusiastic about CI for this particular package. First of all, there are few problems to catch because there is no test suite. (And there is no test suite because the package is basically done, and the algorithms are all fairly simple; they were tested through other packages.) And secondly the rate of new GHC releases seems to outpace the required updates to keep the code working by far, so I'm afraid it would just be an extra maintenance burden.

[andreasabel]

Thanks, Bertram @int-e!

In this case, CI would ensure just buildability with the recent GHCs. Updating this once per GHC major version release can catch problems like the OP.

[andreasabel]

You could also have cherry-picked the fix for:

• .cabal file: git:// protocol no longer supported #6

[int-e]

I'm still not convinced about CI. What would avoid this kind of problem would be a habitual check whether the package still builds when a new GHC is released. Adding CI to the repo doesn't establish that kind of habit since the version range is maintained manually (and AFAIK CI runs aren't triggered without repo activity anyway).

[andreasabel]

What helps to stay up-to-date is Stackage membership. I filed this package for such:

• Add union-find-array commercialhaskell/stackage#7402

Would you like to be notified when union-find-array falls out of the Stackage nightly set (because of outdated dependencies or build failures)? Then I'd put you there as contact person rather than me (I would prefer this).