#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 at 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