[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Claus Reinke]

> 1. Document the version numbering policy.

agreed. just making everybody's interpretation explicit has
already exposed subtle differences, so documenting common
ground will help.
 
> We should have done this earlier, but we didn't.  The proposed policy, for 
> the sake of completeness is: x.y where:
> 
>   x changes ==> API changed
>   x constant but y changes ==> API extended only
>   x and y constant ==> API is identical
> 
> further sub-versions may be added after the x.y, their meaning is 
> package-defined.  Ordering on versions is lexicographic, given multiple 
> versions that satisfy a dependency Cabal will pick the latest.

referring to a haskell function to compute ordering, or to parse
version strings into lists of numbers, might remove ambiguities
here. for instance, some people use patch-levels as sub-versions,
some use dates.

also, compare Simon's (S) with Daniel's (D) version:

| If the convention for modifying package versions of form x.y.z is:
|  - increment z for bugfixes/changes that don't alter the interface
|  - increment y for changes that consist solely of additions to the interface, 
|    parts of the interface may be marked as deprecated
|  - increment x for changes that include removal of deprecated parts of the 
|   interface

version D gives us strictly more information from a version 
number: just from number differences, we can tell what kind 
of changes happened to the api. i like that.

version S is closer to current practice, which is less informative
but psychologically motivated:-) if one does a substantial
rewrite without changing the api, or if one adds fundamentally
new features without breaking backwards compatibility, one 
likes to bump the leading number (that is no doubt inspired by
commercialism: paying customers are said to prefer higher 
version numbers, and to focus on new features). 

corollary: after fixing the version numbering policy (policies?),
the implications on usage need to be investigated (sorting wrt
dates? does a version number tell us anything about which
version can stand in for which dependency?).

> 2. Precise dependencies.
> 
> As suggested by various people in this thread: we change the convention so 
> that dependencies must specify a single x.y API version, or a range of 
> versions with an upper bound.  Cabal or Hackage can refuse to accept 
> packages that don't follow this convention (perhaps Hackage is a better 
> place to enforce it, and Cabal should just warn, I'm not sure).
> 
> Yes, earlier I argued that not specifying precise dependencies allows some 
> packages to continue working even when dependencies change, and that having 
> precise dependencies means that all packages are guaranteed to break when 
> base is updated.  However, I agree that specifying precise dependencies is 
> ultimately the right thing, we'll get better errors when things break,

agreed. please note, however, that this is likely to flush out
issues that have so far been swiped under the carpet. this is
a good thing, as it will lead to proposals for making cabal deal
with these issues properly (replacing unspecified user complaints
with concrete bugs and fixes). but it will increase the noise!-)

claus