Incorrect upper bounds generated

[brprice]

Consider the following sequence of commands

• cabal-edit latest optics: says the latest is optics ^>= 0.4
• cabal-edit add optics: adds the dependency optics ^>= 0.4
• cabal-edit update optics: changes the dependency to optics >=0.4 && <=0.5 (Note the use of <= here)

There two things to note here. A minor distraction is that upgrading an up-to-date package changed the cabal file. The much more important thing is that this upper bound is incorrect!

This claims we will be compatible with an as-yet-unreleased new major version of optics. I don't think that this is what the version bound should be. I expect I should have either of

• optics >=0.4 && <0.5, (which is equivalent to the original bound). This says "compatible until the next major version bump".
• optics >=0.4 && <=0.4 (I chose a bad example here, for a current dependency of dep ^>= 1.2.3.4 and a newer version of 1.7.8.9 we would get dep >=1.2.3.4 && <= 1.7.8.9). This says "compatible with the currently-released version, but maybe not anything later, even minor/patch releases".

I think the confusion in the code is between

cabal-edit/exe/Main.hs

Line 387 in 3e509ba

let ver' = majorUpperBound latestVer

(computing the new version to pass to upgrade - note that majorUpperBound computes the next-greater major version - and

cabal-edit/exe/Main.hs

Line 168 in 3e509ba

upgrade pk latest (_, cabalFile) =

&

cabal-edit/exe/Main.hs

Line 205 in 3e509ba

let ver' = intersectVersionRanges (orLaterVersion prev) (orEarlierVersion latest)

where the upgrade function seems to use it as the latest version (thus putting a <= bound).

I think the fix should be straightforward and am willing to send a PR once it is clear which of the two options would be preferable. (Note to self: potentially is worth adding a lint pass to detect a <= bound on a non-existing version number?)