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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
