On Thursday 18 October 2007 00:54, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > > http://haskell.org/haskellwiki/Package_versioning_policy
Is there technical reason for the major version number to consist of 2 components? Why not 3, 17 or (my preference) 1? Using major.minor instead of A.B.C, and interpreting MUST, SHOULD, MAY as specified by whatever RFC it is that specifies them, I'd write the change rules as: 1. If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or instances were added or removed, then the new major MUST be greater than the previous major (other version components MAY change). 2. Otherwise, if only new bindings, types or classes were added to the interface, then major MUST remain the same and the new minor MUST be greater than the old minor (other version components MAY change). 3. Otherwise, major.minor MUST remain the same (other version components MAY change). Why? - It gives the reader of the version numbers more information, which in turn may allow hackage to do more automated enforcement/testing/upgrading. - To safely specify dependencies you must use an upperbound of the next major version. The stricter change rules make it less likely that a package will miss out on the use of a new version of a dependency that is actually compatible but had it's version bumped anyway. The proposal isn't clear on whether this is allowed or not, but I think sets of version bounds are needed. Using A.B.C <==> major.minor.patch and interval notation for brevity: build-depends: foo [2.1, 3) U [3.3, 3.4) Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe