Using base version bounds to determine GHCs to test with

[parsonsmatt]

To support the * automagic * nature of this plugin, it'd be cool to additionally support base version bounds for generating CI. While this is convenient (don't have to specify a Tested-With clause), it's also great for bounds checking.

A base constraint with no upper bound would "opt in" to be tested, automatically, once new versions of GHC are released. This would alert library authors to breaking changes in their CI much more quickly than if they were to opt-in.

Likewise, a base constraint with no lower bound would have lots of old GHCs to test with. This would help prevent problems where a feature of a new GHC is used and the CI suite doesn't manually test old enough versions of GHC.

But, IMO, the best part about this would be that it would take into account the information that cabal actually uses when providing dependencies. If I say tested-with: GHC == 8.10 || == 9.0 || == 9.2 || == 9.4, but I've got base < 5, then cabal will happily try to build my library with GHC 8.2 or 9.6. Both are likely to break.

[Kleidukos]

It's a good question. Usually what you want is also to specify the latest patch of a Major.minor version. For instance, the 9.x series was impacted by problems related to the native ARM codegen and the macOS platform, and typically you want to advertise that you support the latest patch version (and as such, that you're willing to get tested said latest patch version)

We could indeed take more information into account. Hell, Cabal itself could take more information into account. However, this requires a design that promises more (in terms of reliability) and I'm not sure if I want to take such a commitment right now.

All of this to say: I'm not fundamentally opposed, you make good points, but this needs more brain time for the design and then a bit more later to maintain, and I'm not sure I can afford it.