[Hackage] #435: ban upwardly open version ranges in dependencies on base
#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 | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- This is wrong! {{{ build-depends: base }}} This is still wrong! {{{ build-depends: base >= 3 }}} Each major release of the base package breaks most packages. Packages should specify an upper bound on the base version. Eg: {{{ build-depends: base >= 3 && < 4 }}} or equivalently: {{{ build-depends: base == 3.* }}} Cabal should check for this and suggest a sensible upper version on the base package, given that we know that base follows the package version policy. Note this is a special case for base but in general we should do this for all packages that opt-in to the versioning policy (see #343). Doing it for all such packages is a medium term goal. Doing it for base is quick and easy and has a lot of immediate benefits for the next release of base. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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: ----------------------------+----------------------------------------------- Old description:
This is wrong! {{{ build-depends: base }}}
This is still wrong! {{{ build-depends: base >= 3 }}}
Each major release of the base package breaks most packages. Packages should specify an upper bound on the base version. Eg:
{{{ build-depends: base >= 3 && < 4 }}} or equivalently: {{{ build-depends: base == 3.* }}}
Cabal should check for this and suggest a sensible upper version on the base package, given that we know that base follows the package version policy.
Note this is a special case for base but in general we should do this for all packages that opt-in to the versioning policy (see #343). Doing it for all such packages is a medium term goal. Doing it for base is quick and easy and has a lot of immediate benefits for the next release of base.
New description: This is wrong! {{{ build-depends: base }}} This is still wrong! {{{ build-depends: base >= 3 }}} Each major release of the base package breaks most packages. Packages should specify an upper bound on the base version. Eg: {{{ build-depends: base >= 3 && < 4 }}} or equivalently: {{{ build-depends: base == 3.* }}} Cabal should check for this and suggest a sensible upper version on the base package, given that we know that base follows the package version policy. Note this is a special case for base but in general we should do this for all packages that opt-in to the versioning policy (see #434). Doing it for all such packages is a medium term goal. Doing it for base is quick and easy and has a lot of immediate benefits for the next release of base. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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:
----------------------------+-----------------------------------------------
Changes (by duncan):
* cc: ross@soi.city.ac.uk (added)
Comment:
{{{
Mon Jun 1 20:16:29 BST 2009 Duncan Coutts
#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 ross): You will need to get GHC releases of core packages to follow the PVP strictly if you do this. For example, every package that had a proper upper bound on base was broken by the release of GHC 6.10.2, which bumped the major number of base. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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:3 ross]:
You will need to get GHC releases of core packages to follow the PVP strictly if you do this.
It'd certainly be much more consistent though I'm not sure it's strictly necessary. I mean, I don't think we need to wait. The sooner we get hackage to enforce this, the larger the set of packages that will move over smoothly when we get base 5. 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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): I've done a survey on the last 20 uploaded packages and the new check is accurate in every case. I think it's worth getting this onto hackage. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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 ross@soi.city.ac.uk): Replying to [comment:4 duncan]:
Replying to [comment:3 ross]:
You will need to get GHC releases of core packages to follow the PVP strictly if you do this.
It'd certainly be much more consistent though I'm not sure it's strictly necessary. I mean, I don't think we need to wait. The sooner we get hackage to enforce this, the larger the set of packages that will move over smoothly when we get base 5.
OK, I missed that you were just talking about base (but base is still a problem).
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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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
#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:7 duncan]:
I think it does actually follow the PVP.
The reason that base was bumped from 4.0.0.0 to 4.1.0.0 was because of incompatible API changes in at least one GHC.* module (GHC.Conc). We've decided that in future the GHC.* modules that are not supposed to be for public consumption will not be considered for the purposes of the PVP. The aim will also be to not generate haddock docs for the GHc.* modules that are not generally public (eg GHC.Exts is public). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#435: ban upwardly open version ranges in dependencies on base ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Now done. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/435#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage