Re: Why upper bound version numbers?

On 2016-06-09 at 19:43:42 +0200, David Fox wrote: >> or even worse silent failures where the code behaves >> subtly wrong or different than expected. Testsuites mitigate this to >> some degree, but they too are an imperfect solution to this hard >> problem. > ​It seems to me that if you have any

Re: Why upper bound version numbers?

@haskell.org" <ghc-devs@haskell.org> Sent: Thursday, June 9, 2016 10:43 AM Subject: Re: Why upper bound version numbers? On Mon, Jun 6, 2016 at 11:15 PM, Herbert Valerio Riedel <hvrie...@gmail.com> wrote: or even worse silent failures where the code behaves >subtly wrong or d

Re: Why upper bound version numbers?

On Mon, Jun 6, 2016 at 11:15 PM, Herbert Valerio Riedel wrote: > or even worse silent failures where the code behaves > subtly wrong or different than expected. Testsuites mitigate this to > some degree, but they too are an imperfect solution to this hard > problem. > ​It

Re: Why upper bound version numbers?

My five cents: There is discussion/work in Cabal dev about splitting the solver out. [1] I hope that at the end, there will be functionality that you can construct build/install plan by whatever means and use cabal functionality to execute it. Another functionality brought by work on

Re: Why upper bound version numbers?

Versions of package dependencies can be categorised into 5 sets: D1) Versions which the maintainer has tested and found to work D2) Versions which the maintainer has not tested but expects to work D3) Versions which the maintainer has tested and found to not work D4) Versions which the maintainer

Re: Why upper bound version numbers?

Sure, I'm just wondering about how this plays out in reality: of people getting unsolvable plans, how many are due to hard upper bounds and how many due to soft upper bounds? We can't reliably tell, of course, since we don't have this distinction currently, but I was trying to get some anecdotal

Re: Why upper bound version numbers?

I think "hard" upper bounds would come about in situations where a new version of a dependency is released that breaks things in a package, so until the breakage is fixed a hard upper bound is required. Likewise for hard lower bounds. And arguments about "it shouldn't happen with the PVP" don't

Re: Why upper bound version numbers?

What do you expect will be the distribution of 'soft' and 'hard' upper bounds? In my experience, all upper bounds currently are 'soft' upper bounds. They might become 'hard' upper bounds for a short while after e.g. a GHC release, but in general, if a package maintainer knows that a package fails

Re: Why upper bound version numbers?

Right, part of the issue with having dependency solving at the core of your workflow is that you never really know who's to blame. When running into this circumstance, either: 1) Some maintainer made a mistake. 2) Some maintainer did not have perfect knowledge of the future and has not yet

Re: Why upper bound version numbers?

> On 8 Jun 2016, at 6:19 pm, Reid Barton wrote: > > Suppose you maintain a library that is used by a lot of first year uni > students (like gloss). Suppose the next GHC version comes around and your > library hasn’t been updated yet because you’re waiting on some

Re: Why upper bound version numbers?

On Tue, Jun 7, 2016 at 9:31 AM, Ben Lippmeier wrote: > > > On 7 Jun 2016, at 7:02 am, Dominick Samperi wrote: > > > > Why would a package developer want to upper bound the version number > > for packages like base? For example, the clash package requires

Suggestions for improving the PVP. Was Re: Why upper bound version numbers?

On Monday, June 6, 2016 23:15:00 -0700, Herbert Valerio Riedel wrote: > Unfortunately, GHC's `base` package has a *huge* API surface. So with> each > GHC release we're usually forced to perform a major version bump to > satisfy the PVP, even if just a tiny part only very few packages use of >

Re: Why upper bound version numbers?

> On 7 Jun 2016, at 7:02 am, Dominick Samperi wrote: > > Why would a package developer want to upper bound the version number > for packages like base? For example, the clash package requires > > base >= 4.2 && base <= 4.3 I put an upper bound on all my libraries as a

Re: Why upper bound version numbers?

Others have already commented on many aspects of this discussion, but I just wanted to mention that cabal has an '--allow-newer' flag to disregard these constraints, so '--allow-newer=base' would allow you to try and compile this package with GHC 8. Since GHC 8 is very recent though and base 4.3

Re: Why upper bound version numbers?

Given that I'm the maintainer of the 'clash' package, I wanted to say that the 'clash' package has been deprecated in favour of the 'clash-ghc' package (for some time now, and this is stated on hackage). Sadly, 'clash-ghc' will not compile on ghc 8.0.1 right now either; it only compiles

Re: Why upper bound version numbers?

On 2016-06-07 at 02:58:34 +0200, Dominick Samperi wrote: > I guess what you are saying is that this policy will prevent packages > from installing with new versions of ghc until the maintainer has had > a chance to test the package with the new version, and has updated the > upper version limit.

Re: Why upper bound version numbers?

Aforementioned versioning policy: https://wiki.haskell.org/Package_versioning_policy On Mon, Jun 6, 2016 at 5:58 PM, Dominick Samperi wrote: > I guess what you are saying is that this policy will prevent packages > from installing with new versions of ghc until the

Re: Why upper bound version numbers?

I guess what you are saying is that this policy will prevent packages from installing with new versions of ghc until the maintainer has had a chance to test the package with the new version, and has updated the upper version limit. Thus, inserting those upper version limits is a kind of flag that

Re: Why upper bound version numbers?

On Mon, Jun 6, 2016 at 8:19 PM, Dominick Samperi wrote: > The odd thing about this is that to upper bound a package that you did > not write (like base) you would have to know that incompatible changes > were coming in subsequent revisions, or that features of the API that >

Re: Why upper bound version numbers?

The odd thing about this is that to upper bound a package that you did not write (like base) you would have to know that incompatible changes were coming in subsequent revisions, or that features of the API that you rely on will be changed. The upper bound makes perfect sense for packages that you

Re: Why upper bound version numbers?

On Mon, Jun 6, 2016 at 5:02 PM, Dominick Samperi wrote: > Consequently, it refuses to install with the latest ghc provided with > the Haskell Platform (8.0.1). > base is not defined by the Platform, it is defined by (and ships with, and must completely match) ghc. And no,

Why upper bound version numbers?

Why would a package developer want to upper bound the version number for packages like base? For example, the clash package requires base >= 4.2 && base <= 4.3 Consequently, it refuses to install with the latest ghc provided with the Haskell Platform (8.0.1). Does this mean that assuming that