Closed DougBurke closed 6 years ago
Thank you for the pr. I'll look more into it tomorrow. Perhaps it's time to drop support for 7.8.
My use of groundhog is more academic than commercial, so I am perhaps free-er than many in being able to upgrade ghc versions when I want.
Yes, keeping compatibility for as long as possible is a good idea. Usually the cost for that was low - a couple of CPP pragmas here and there. But if we need to use older libraries and make the code harder to read with combine
, I'd vote for dropping some older versions - 7.8 has been around for four years. I think that if someone decided to use Haskell in a commercial environment, they must be open to innovation and perhaps updated long time ago.
There may well be a better way of achieving compatibility with ghc 7.8 and libraries - I just flailed around until I hit on a combination that built! However, I don't see it as a problem if you drop ghc 7.8 either.
Add support for GHC 8.4.
I have tweaked the test system (using separate stack.yaml files for each LTS) rather than the "supply the resolver on the command-line" approach, since this was easier for me to deal with the changes to the "extra packages" needed with older LTS versions.
I am not happy about the needed postgresql change, as it essentially copies over the Semigroup/Monoid change made to postgresql-simple - see https://github.com/lpsmith/postgresql-simple/commit/44c0bb8dec3b71e8daefe104cf643c0c4fb26768#diff-75d19972de474bc8fa181e4733f3f0d6R94 - and I would hope there's a better solution. I applied the same solution to MySQL.
If this is an acceptable solution I can rebase this patchset to clean up the commit history.