[Hackage] #435: ban upwardly open version ranges in dependencies on base

[Hackage]

#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