On Thursday 16 December 2010 11:08:23, Johannes Waldmann wrote:
But: I'm always puzzled by build-dependencies like "A <= 3.4.5". With the "major.minor.release" scheme, a change in "release" means no API change (just bugfix), in "minor" means compatible extension of API, and only "major" changes can break the API. So, I could understand "A = 3.*" but anything that mentions
But according to http://www.haskell.org/haskellwiki/Package_versioning_policy the major version is A.B and C is the minor version, so "A < 3.5" is a reasonable constraint if the package is known to work with A-3.4.x but hasn't been tested with A >= 3.5. The problem is that without upper bounds, things will break a lot when packages undergo API changes, but probably more often things will also work with the new API. So with upper bounds, you prevent breakage at the cost of preventing builds which would work. Maybe a flag "ignore upper bounds and try with the latest" for cabal would be a solution. Would that be hard to implement or easy?
minor and release numbers is really a quite pessimistic view of the world. Actually, I read "A <= 3.4.5" as "my package depends on a bug in package A that was fixed in 3.4.6"
Or: it breaks with a bug introduced in 3.4.6 which hasn't yet been fixed.
J.W.