HTTP package - supported GHC versions

[Ganesh Sittampalam]

Do you (or anyone else) have any sense of how common GHC 7.0 usage is in
practice?

I do like the idea in principle of supporting old compilers, but it does
come with a cost even if the code works with them right now.

Also, if there's anyone out there that depends on HTTP and wants to
support GHC 7.0 for whatever reason, that would swing it for me.

On 04/09/2014 07:23, Andreas Abel wrote:
> If it is not too much of a hassle, rather support old versions of GHC.
> As mentioned below, there are long term support versions of Linux that
> package older GHCs.
> 
> I was positively surprised that the latest QuickCheck still supports GHC
> 6.8.  Agda aims to support GHC 7.0 for a while still (which keeps me
> from using some nice syntax extensions to Haskell).
> 
> Cheers,
> Andreas
> 
> On 03.09.2014 19:09, Herbert Valerio Riedel wrote:
>> Hi,
>>
>> On 2014-09-03 at 14:25:39 +0200, Ganesh Sittampalam wrote:
>>
>> [...]
>>
>>> 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.
>>
>> I don't have any strong opinion on "last three major GHC versions (with
>> an associated HP release)" vs "the first Haskell2010-supporting GHC
>> on-wards", either are fine with me, as even the latter one would
>> typically span a 3-4 year window (which would be good enough for most
>> Linux distros except certain "enterprise" ones...)
>>
>> However, one should just be aware that the lower your package is in the
>> dependency graph, the larger the transitive avalanche effect of forcing
>> newer lower-bounds on packages depending upon yours is.  Otoh, at some
>> point this is bound to happen anyway...
>>
>> Cheers,
>>    hvr
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> 
>