HTTP package - supported GHC versions

Ganesh Sittampalam ganesh at
Wed Sep 3 12:25:39 UTC 2014

On 03/09/2014 08:51, Herbert Valerio Riedel wrote:
> On 2014-09-02 at 23:24:25 +0200, Ganesh Sittampalam wrote:
> [...]
>> For future releases I plan to drop most of these. Any opinions about how
>> far back it should support?
>> I'm thinking restricting it to either 7.4+ or 7.6+, but I'm open to
>> keeping support for older versions too if there's a real need.
> Personally, I think supporting GHC 7.0+ is a natural boundary, as GHC
> 7.0.1 was the first to support Haskell2010. 
> Are there any specific GHC 7.4+ features you want to use, or any other
> inconveniences (other than keeping an ghc-7.0.4 entry in the travis.yml
> file) that would increase the cost to keep supporting GHC 7.0.x?

The main burden is the testing overhead. Travis is nice to have but
doesn't buy me that much as it doesn't build or run the tests.

I'm not aware of any specific GHC 7.4+ features. However the test
harness partially depends on warp which I couldn't get to build with
GHC<=7.0, so needs an extra flag to disable those tests which it'd be
nice to clean out.

Generally I find that the older the GHC, the more likely it is that the
dependencies will be difficult and require hardcoded constraints in the
test script, though GHC 7.0 isn't currently causing any problems there.

More generally I'm not too keen on having a lower bound that is "stuck",
rather than moving forwards in a routine fashion as new GHC and Haskell
Platform releases appear. So I like the "three versions" rule and I
don't like "the first Haskell2010-supporting GHC onwards".

All that said I do like the general idea of supporting a wide range of
GHCs with a low-level library like this and I'm happy to do so if
there's some plausible value in it.



More information about the Libraries mailing list