Is it possible to specify a version range in the [compat] section in Project.toml?
In particular, I’d like to specify a range including both 0.7 and 1.0, indicating that the package works for all versions from 0.7 to 1, including both, but not any version with e.g. 2.x, as a safety measure for when that version will be released.
The intersection of multiple version specifiers can be formed by comma separating indiviual version specifiers.
and that seemed to work fine, but when trying it out by changing the upper bound to 1.0, it added without error on 1.0, even though it should only be possible to add that package to 0.7, if I understand correctly.
Yes, that works for [1.0, 2.0) - but what about [0.7, 2.0)? Or any version jump greater than one major version? Using just ^1 gives a warning on 0.7, even though it’s very reasonable that code written for 1.0 also works on 0.7.
EDIT: ah, did you mean julia = ">= 0.7, ^1"? That indeed seems to work, although cumbersome when it’s possible to support multiple major version jumps, e.g. ">=0.7, ^1, ^2, ^3, ..."… Is there a better way?
Adding on to this, the docs talk about the “intersection” of version ranges, but specifying julia = ">= 0.7, ^0" does not prevent a package from being added on 1.0 - in fact, it works without any warning at all. Is there some undocumented precedence? Or is this just an unlikely (hopefully never again relevant) edge case with the major version jump 0 -> 1?
The reason I’m asking about this is because this is leading me to believe that the intersection does in fact not work as described in the documentation, as both those conditions together should prevent the package from being installed on 1.x, as I understand it. Those conditions should be equal to a version range of [0.7, 1.0) - note the jump in major version, which I don’t think can be expressed otherwise. Since that example didn’t work for me, I think it also won’t work for [0.7, 2.0) - no way for me to test that at the moment though
I think that julia = ">= 0.7, ^1" should solve your original problem (not allowing a new major version until it is tested), and supporting a large number of major (= breaking API changes) versions of some dependency (or the major language) is not a typical use case, as it would involve a lot of conditional boilerplate code. In the unlikely case this happens, adding an extra ^n is not a major burden.