On Thu, 2009-06-04 at 09:13 +0000, kahl@cas.mcmaster.ca wrote:
[Not replying to haskell-cafe since not subscribed.]
Duncan wrote:
There is no way for the tools to discover if you mean base 3 or 4 and yet most packages break when we pick the wrong one. You must specify an upper bound so that your package does not break when the next major version of the base library is released.
For example, if you've tested with base 3 and 4 then use:
build-depends: base >= 3 && < 5
Then ``build-depends'' is a misnomer because most packages will most likely not DEPEND on the fact that the used base package has version less than 5.
It depends on how much base 5 changes from 4 as to the likelihood of the package breaking. Looking back at the days of base 2, I think retrospectively we can reasonably say that all the packages that used "build-depends: base >=2" really did "DEPEND" on the fact that the used base package has version less than 3. The transition to base 3 was very disruptive, only the most trivial programs did not break. It's true that it's pessimistic and based on future unknowns. Other people have also suggested that it should not be "depends" but something else to say that it's a speculative upper bound rather than a known one based on testing.
This misnomer is one major source of my uneasiness with cabal.
The upper bound bits specifically or generally using version ranges? Version ranges do only make sense when you know the versioning policy of the package you're depending on, so that you know how changes in future versions of the package will be reflected in version number changes.
I would like to propose ``tested-with'' as a better name, and would like to see a way for users to easily test with a version I did not have avaliable, and report that back (perhaps to hackage).
Certainly speculatively trying with later versions and reporting is a useful thing. Doing it via hackage build clients and emailing authors would be nice.
Of ocurse, I can, for example, honestly only write
tested-with: base `elem` [2.1.1, 3.0.1.0, 3.0.3.1, 4.1.0.0]
because those are the versions I happen to have lying around, and you probably would like to allow building with
Given that you know the versions that worked and you know that the package in question is following the PVP (otherwise none of this makes sense) then you can derive the upper bounds you're interested in.
But in general there is no guarantee that a give package actually implements that, or does hackage test for compliance with the version convention?
Right, it only makes sense if you know the versioning policy of the package. In particular we know base follows the PVP. An idea is to let packages opt-in to following a named version policy (eg the PVP).
Yet another problem is that if I write
tested-with: pkg1 == v1_1 || == v1_2 ... pkg9 == v9_1 || == v9_2
, I probably won't have tested all 2^9 combinations...
Yes, we have to assume some kind of independence. Clearly version numbers are an approximation of precise type (and semantic) interfaces. It's not a total solution but should help significantly reduce the number of packages that needlessly break in confusing ways when end-users upgrade things. We're certainly not trying to suppress ideas or work on better, more complete solutions. In the mean time we're trying to reduce the expected pain of breakage at major transitions. Duncan