PVP proposal: no upper bounds on non-upgradeable packages

[Adam Bergmark]

>
> 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 at 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 at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/libraries
>>> >
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/c3546aac/attachment.html>