Why is there an upper bound on Opaleye

[tomjaguarpaw]

I'm the Opaelye maintainer. I see there's an upper bound on Opaleye

lts-haskell/build-constraints/lts-22-build-constraints.yaml

Line 1761 in b638728

- opaleye ^>= 0.10.2.0 && < 0.10.4

as imposed in this commit: 1cfddfa#diff-58e26863dfb39461dede8943ad0bd4648278048ebe574a061d83701e49abb2a2

Why? Is there something I should be doing to make opaleye-0.10.4.0 suitable for LTS Haskell?

[mihaimaruseac]

This is because

uuid-types-1.0.5.1 (changelog) (Grandfathered dependencies) is out of bounds for:

• opaleye-0.10.4.0 (>=1.0.6 && < 1.1). Tom Ellis [email protected] @tomjaguarpaw. Used by: library

On LTS we don't notify owners again (maybe we should?), we just try to make the snapshot consistent. LTS starts with the state of the nightly when the first LTS in the series starts and after that we only add bounds to do minimal changes to the snapshot.

[mihaimaruseac]

uuid-types got an upper bound in cf46210 for similar reasons.

[tomjaguarpaw]

Thanks, I revised opaleye-0.10.4.0 to allow uuid-types >= 1.0.5: https://hackage.haskell.org/package/opaleye-0.10.4.0

Is there anything I need to do to get the upper bound on Opaleye removed in the LTS?

[tomjaguarpaw]

On LTS we don't notify owners again (maybe we should?)

If I had been notified I would have been able to address this sooner. As it happened, I discovered this upper bound out of idle curiosity, whilst I was investigating LTS for unrelated reasons (adding bluefin). At the very least I think it would be useful to add the reason for the upper-bounding into the commit message.

[mihaimaruseac]

That makes sense. I started adding the reason in the commit message and I think other curators will too.

Meanwhile, I pushed a commit to remove the upper bound, but sadly I already did this week's LTS.

[tomjaguarpaw]

OK, thanks. That's fine, as long as everything is set up correctly to get the latest Opaleye in due course.