#435: ban upwardly open version ranges in dependencies on base ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:6 ross@soi.city.ac.uk]:
We've been treating base as if it were just had one major version digit rather than the two specified by the PVP. Most packages follow this too, using just ">= 3 && < 4" etc.
And yet version numbers of base have 4 components -- I think the situation is unclear, and we need a clear statement if these constraints are to be meaningful.
I think it does actually follow the PVP. The base package is a bit tricky since it's so large. A single change anywhere is a major version bump but in practise most packages will not break. We do not yet have the mechanism to easily adjust dep constraints after a package has been released so there is a danger of being too strict, where we tell everyone to use `build-depends: base < 4.2` and then ghc-6.12 makes one minor change that only really breaks a couple program but has to bump to 4.2. For an intermediate solution I'd be quite happy to just encourage `build- depends: >= 2 && < 5`. Where it's still slightly sloppy but vastly better than 'build-depends: base'. What we should aim for is the infrastructure to test packages against new versions of their deps and to be able to more easily adjust already released packages's deps and then to do this checking more generally for all packages that opt-in to the PVP. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects