brick's versioning scheme doesn't seem to follow haskell PVP specification.

[amano-kenji]

In A.B.C, A.B is the major version. C is a minor version number.

When I read CHANGELOG.md, it seems brick-1.7 doesn't actually have breaking changes to 1.6.

If there is no breaking change and major version changes, it's hard to fix an upper version limit for brick.

[jtdaugherty]

With brick, I use a more conservative definition of "breaking change." The 1.7 release makes an API addition, which can definitely break builds if the thing that got added clashes with a binding in the affected program. I increment the second version component whenever the API changes in any way, not just when things are removed or changed in place. I increment the third component only on bug fixes or behavioral fixes that do not change the API at all. I'll add a note about this to the README.

As for upper bounds, I recommend setting the upper bound to whatever version of brick you developed with originally and then checking periodically for compatibility of your particular codebase with newer versions of the API.