Are you aware that there's a tested-with field in cabal for exactly that purpose? I'm not sure why you'd prefer a proxy variable with side-effects to the real thing.

I did not consider tested-with! I would be okay with using this instead of upper bounds if it implied constraints on non-upgradeable packages. To not break all of hackage the omission of this field should mean "no version bounds" (and some packages don't depend on base). From what I've seen usage of this field is very rare, which might change if cabal-install actually does something with it. Then we can gradually shift towards not allowing this field to be omitted. --allow-newer needs to be able to override this as well.
 
 
I don't understand what you're saying here. How do maintainers get extra time by having an upper bound on base? Either way, beta testers of GHC will be sending reports to please support the new GHC, this just makes it slightly easier for those beta testers to get useful reports to maintainers.

I think I phrased this poorly, sorry, please disregard that part. The upper bound signals what the maintainer knows about the package (ie. it has not been tested with higher versions) and beta testers will then see this, l think it's useful for them to know whether the maintainer is ahead of them. I do think --allow-newer is the proper solution here, I consider being a beta tester more nuclear than using --allow-newer :-)

 

On Thu, Apr 10, 2014 at 12:57 AM, Ganesh Sittampalam <ganesh@earth.li> wrote:
-1 (because of the listed downsides)

On 09/04/2014 20:24, Michael Snoyman wrote:
> At Herbert's request, I'm splitting off this part of the PVP proposal I
> made[1] to its own separate proposal. Same discussion period of three
> weeks. The proposal is:
>
> Upper bounds should not be included on non-upgradeable packages, such as
> base and template-haskell (are there others?). Alternatively, we should
> establish some accepted upper bound on these packages, e.g. many people
> place base < 5 on their code.
>
> The purpose (elaborated in my blog post[2]) is that these upper bounds
> virtually never provide for a successful build. Instead, they are purely
> about what error messages the user receives. With this change:
>
> * Some build plans that would have previously been impossible are now
> possible, without resorting to the nuclear option of --allow-newers.
> * Instead of cabal version bound error messages, users get GHC compiler
> errors that can be fed back upstream to help get packages fixed more
> expediently.
>
> Downsides I'm aware of:
>
> * If you consider the cabal error messages more user friendly, then the
> error message quality goes down.
> * Users may find out later than they do right now about a failing build.
>
> [1] http://www.haskell.org/pipermail/libraries/2014-April/022529.html
> [2] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
>
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries