search

basvandijk / case-insensitive

Case insensitive string comparison
Other
25 stars 19 forks source link

Support text-1.1 #13

Closed DougBurke closed 10 years ago

wraithm commented 10 years ago

Just out of curiosity, when will this patch be added to hackage?

AaronFriel commented 10 years ago

I feel like I'm following a trail of breadcrumbs left by DougBurke now, but I'm going to second this patch and possibly recommend bumping the upper bound to 2.0. Why increase the text upper bound a little when you can bump it a lot?

basvandijk commented 10 years ago

Thanks! Released as case-insensitive-1.1.0.3.

Why increase the text upper bound a little when you can bump it a lot?

It's just strictly following the PVP. If the text library has a major version bump it means the API could have changed in a way that breaks case-insensitive. To protect against this I only support text up until and including the major version that I tested it with.

AaronFriel commented 10 years ago

The problem is, that policy makes Hackage very brittle to version bumps and as a consequence, no one wants to bump major versions. It leads to inefficiencies with Hackage in terms of updating packages for changes that don't affect most consumers. If there's anything the average Haskell user would say about Hackage, it's definitely not that updates are timely.

Given the sheer number of times there are problems with upper bounds being specified too strictly, don't you think it's time to start erring on the other side?

DougBurke commented 10 years ago

I've been bitten by problems when upper bounds aren't given, something has changed, and you end up in a mess of compilation errors. At the moment I'd prefer to have 'guaranteed' compilation rather than access to the latest and greatest (although I will note that testing with text 1.1 was a lot easier because many of my dependencies use "text -any").

Doug On Jan 18, 2014 9:24 PM, "Aaron Friel" notifications@github.com wrote:

The problem is, that policy makes Hackage very brittle to version bumps and as a consequence, no one wants to bump major versions. It leads to inefficiencies with Hackage in terms of updating packages for changes that don't affect most consumers. If there's anything the average Haskell user would say about Hackage, it's definitely not that updates are timely.

Given the sheer number of times there are problems with upper bounds being specified too strictly, don't you think it's time to start erring on the other side?

— Reply to this email directly or view it on GitHubhttps://github.com/basvandijk/case-insensitive/pull/13#issuecomment-32699335 .

basvandijk commented 10 years ago

Ideally we would have soft and hard bounds. Soft bounds mean that the maintainer has successfully tested the package within the bounds but the package may work outside the bounds. Hard bounds mean that the package won't work outside the bounds. Cabal should then have an option to ignore soft bounds.