Please avoid the version bump in the PR. I'll do that myself (along with other things) between merge and release.

Sure thing!

Are these strictly needed? I have no issue with bumping upper bounds, but I'd like to avoid extra-deps here since it affects CI and could give false-negatives (positives?) when checking the nightly build, etc.

I've discussed this with a co-maintainer before, I'll remove it for now but share the reasoning:

If I bump dependency bounds to support some new version of a library or libraries, it makes sense to me that I'd want to pin those newest versions and check that the project continues to build against them. Arguably it's slightly more necessary here as much of this isn't in a stable LTS yet.

Alternative would be to have multiple stack.yamls beyond the usual assortment for different GHC versions, one tracking nightly + pinned versions.

Also it is sort of a "show your work" thing. Shows I was actually building the library against the versions the bounds bump was permitting. You'd be surprised how often I see bounds getting bumped without people doing test builds against the newest versions permitted.

I can see why you might not want it, so I'll remove it.

Thanks for backing it out. That reasoning makes sense and I will give it some more thought. I've been moving towards more comprehensive CI in #44, which includes a build on nightly. So maybe we can do something once that lands that exercises these newer versions explicitly.

I think my stance is that a CI of supported versions + nightly is enough. In other words, I'm comfortable understanding that nightly may or may not currently catch the newest versions our bounds allow, but that when it matters it will. Does that make sense?

Makes sense to me. 👍