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

[Daniel McAllansmith]

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