`persistent` version mismatch about stackage

[sternenseemann]

Stackage should update the manually added constraint for persistent-test to match the other persistent-* packages and ideally build and run the tests for persistent-sqlite and any other packages if possible.

[DanBurton]

1. the persistent-sqlite-2.13.1.1 cabal file doesn't specify the bound, which means stackage's constraint solving allowed for the older version.
2. persistent-sqlite is listed as an expected test failure citing an old issue, which is why the LTS build was considered a success and published, even if that test suite failed.

I do see in the constraints for LTS 20 that range: <2.13.1.3 is used to specifically keep it at the older version, though I'm not sure exactly why this was done.

[ncfavier]

persistent-test 2.13.1.3 requires persistent 2.14, which might be a problem.

[sternenseemann]

This problem also affects persistent-postgresql now.

Here stackage couldn't be expected to figure it out, as running a postgresql db during the test suite is a bit tricky.

I do see in the constraints for LTS 20 that range: <2.13.1.3 is used to specifically keep it at the older version, though I'm not sure exactly why this was done.

As @ncfavier says, persistent-test 2.13.1.3 requires persistent >= 2.14 which is not in stackage. I suspect the extra constraint is necessary, as the dependency on persistent-test is always without constraint, maybe the constraint solver would then pick the latest version and give up instead of backtracking.

[alaendle]

Is there something we could do/clarify from stackage side? Should we re-enable the testing of persistent-sqlite?

[alaendle]

From now on we expect the tests of persistent-sqlite to succeed - and I've found no manual constraints on persistent-* packages (so everything should stay up-to-date - according to PVP on LTS versions). If there is still something strange in latest nightly or lts please reopen to let me know.