Bump version bounds for text 1.2.0.0 (released September 9, 2014)

joeyadams commented 10 years ago

Right now, bytestring is on 0.10.4.0 (not affected by < 1), and text is on 1.2.0.0 (affected by < 1.2). This lets direct-sqlite be built with the latest version of the text package (released on September 9, 2014). I tested cabal install and cabal test do work with these packages under GHC 7.8.3 and cabal-install 1.20.0.3.

I'm not a fan of putting upper bounds on dependencies everywhere, nor is most of the Haskell community (I think...I could be wrong). They force us to update bounds every time a new version of a dependency comes out. On the other hand, this forces us to test to make sure our code actually works with the new version.

This pull request removes the upper bounds entirely. If you instead prefer upper bounds on dependencies, please:

Bump the upper bound of text so we can build with 1.2.
Fix the bound on bytestring to be < 0.10 instead of < 1. That, or fix text to be < 2. As is, the comparisons are inconsistent; the bytestring bound waits for A.x.x.x to change, while the text bound waits for A.B.x.x to change.

nurpax commented 10 years ago

I think it's likely for bytestring and text to break backwards compatibility in their APIs to affect direct-sqlite. (Our uses are fairly limited.) So I'll choose this over my stricter version of the same.

IreneKnapp commented 10 years ago

Yeah - I have come around to the no-upper-bounds view. Not sure how I feel about it for base, but for everything else at least. Semantic versioning is a nice idea, but it doesn't appear to actually work, and even if it did, with Hackage being uncurated, it creates overhead without actually offering benefit.

nurpax commented 10 years ago

I tend to use upper bounds but it indeed leads to a lot of maintenance work. In my Haskell apps (e.g. stuff not on Hackage) I never use upper bounds, other than occasionally cabal freeze'ing.

In this case I'm making an exception as I doubt the APIs of bytestring or text will change radically in the foreseeable future.

IreneKnapp commented 10 years ago

Ah - I had thought I had a counterexample where bytestring did change in a surprising way, but no, it wasn't bytestring at all; it was this issue - https://github.com/lpsmith/postgresql-simple/issues/36 - which is not at all about anything that's bytestring's fault.

nurpax commented 9 years ago

This is now in direct-sqlite-2.3.14 on Hackage.

IreneKnapp / direct-sqlite

Bump version bounds for text 1.2.0.0 (released September 9, 2014) #49