I am tentatively in agreement that upper bounds are causing more
problems than they are solving. However, I want to suggest that
perhaps the more fundamental issue is that Cabal asks the wrong person
to answer questions about API stability. As a package author, when I
release a new version, I know perfectly well what incompatible changes
I have made to it... and those might include, for example:
1. New modules, exports or instances... low risk
2. Changes to less frequently used, advanced, or "internal" APIs...
moderate risk
3. Completely revamped commonly used interfaces... high risk
Currently *all* of these categories have the potential to break
builds, so require the big hammer of changing the first-dot version
number. I feel like I should be able to convey this level of risk,
though... and it should be able to be used by Cabal. So, here's a
proposal just to toss out there; no idea if it would be worth the
complexity or not:
A. Cabal files should get a new "Compatibility" field, indicating the
level of compatibility from the previous release: low, medium, high,
or something like that, with definitions for what each one means.
B. Version constraints should get a new syntax:
bytestring ~ 0.10.* (allow later versions that indicate low or
moderate risk)
bytestring ~~ 0.10.* (allow later versions with low risk; we use
the dark corners of this one)
bytestring == 0.10.* (depend 100% on 0.10, and allow nothing else)
Of course, this adds a good bit of complexity to the constraint
solver... but not really. It's more like a pre-processing pass to
replace fuzzy constraints with precise ones.
--
Chris