Notice for package authors

[Duncan Coutts]

On Thu, 2009-06-04 at 09:13 +0000, kahl at 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