[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
dm.maillists at gmail.com
Wed Oct 17 16:41:15 EDT 2007
On Thursday 18 October 2007 00:54, Simon Marlow wrote:
> I've written down the proposed policy for versioning here:
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
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
- 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)
More information about the Haskell-Cafe