HTTP package - supported GHC versions - Libraries

HTTP package - supported GHC versions

Ganesh Sittampalam

2 Sep 2014 2 Sep '14

5:24 p.m.

Hi, The HTTP package supports a whole load of old GHCs - the current version should actually work with GHC 6.10. 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. Cheers, Ganesh

Show replies by date

Johan Tibell

3 Sep 3 Sep

3:27 a.m.

For the core libraries we typically support the latest 3 major GHC release, so back to 7.4 right now. On Sep 2, 2014 11:24 PM, "Ganesh Sittampalam" wrote:

...

Hi,

The HTTP package supports a whole load of old GHCs - the current version should actually work with GHC 6.10.

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.

Cheers,

Ganesh _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Herbert Valerio Riedel

3:51 a.m.

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? Cheers, hvr

Johan Tibell

4:25 a.m.

On Wed, Sep 3, 2014 at 9:51 AM, Herbert Valerio Riedel wrote:

...

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?

I don't know what the case is for HTTP, but in libraries that I maintain I'm typically able to remove a bunch of ifdefs every time I raise the minimum bar. Now, if we could only stop making breaking changes in GHC/base all the time...

Ganesh Sittampalam

8:25 a.m.

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. Cheers, Ganesh

Johan Tibell

8:37 a.m.

On Wed, Sep 3, 2014 at 2:25 PM, Ganesh Sittampalam wrote:

...

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.

If I were you I would try to fix this issue, as it saves you a lot of time in the long run.

Carter Schonwald

9:37 a.m.

yeah, its very very easy (and rewarding) to get travis to build/run tests, if you need help let us know! On Wed, Sep 3, 2014 at 2:37 PM, Johan Tibell wrote:

...

On Wed, Sep 3, 2014 at 2:25 PM, Ganesh Sittampalam wrote:

...
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.

If I were you I would try to fix this issue, as it saves you a lot of time in the long run.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ganesh Sittampalam

12:35 p.m.

I don't really know much about travis. Johan wrote the config for the HTTP package and then disabled the tests because cabal was failing: https://github.com/haskell/HTTP/commit/bbb2867c03a853ce70e1958adc8ddc5ce6bb2... Perhaps that would be better now, but it does feel like a bit of a black box to me. On 03/09/2014 14:37, Carter Schonwald wrote:

...

yeah, its very very easy (and rewarding) to get travis to build/run tests, if you need help let us know!

On Wed, Sep 3, 2014 at 2:37 PM, Johan Tibell mailto:johan.tibell@gmail.com> wrote:

On Wed, Sep 3, 2014 at 2:25 PM, Ganesh Sittampalam mailto:ganesh@earth.li> wrote:

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.

If I were you I would try to fix this issue, as it saves you a lot of time in the long run.

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Herbert Valerio Riedel

1:09 p.m.

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

Andreas Abel

4 Sep 4 Sep

2:23 a.m.

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Ganesh Sittampalam

8 Sep 8 Sep

5:19 p.m.

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Greg Weber

5:26 p.m.

You are probably unlikely to find the person you are looking for on the libraries mail list on this subject, instead you are only going to find advice :) On Mon, Sep 8, 2014 at 2:19 PM, Ganesh Sittampalam wrote:

...

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Herbert Valerio Riedel

9 Sep 9 Sep

3:53 a.m.

Hi, On 2014-09-08 at 23:19:44 +0200, Ganesh Sittampalam wrote:

...

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

Here's just some rough statistics based on the Hackage access logs of september so far, assuming the heuristic each distinct user can be identified by its IP address (the numbers denote the distinct IP addresses that accessed Hackage with the particular cabal-install version): 89 cabal-install/0.10.2 1 cabal-install/0.10.3 2 cabal-install/0.13.3 780 cabal-install/0.14.0 3 cabal-install/0.17.0 1 cabal-install/0.6.2 28 cabal-install/0.8.0 7 cabal-install/0.8.2 1 cabal-install/0.9.1 2 cabal-install/1.16.0 19 cabal-install/1.16.0.1 2713 cabal-install/1.16.0.2 2 cabal-install/1.17.0 2 cabal-install/1.18.0 16 cabal-install/1.18.0.1 282 cabal-install/1.18.0.2 196 cabal-install/1.18.0.3 45 cabal-install/1.18.0.4 1937 cabal-install/1.18.0.5 1 cabal-install/1.19.0 7 cabal-install/1.19.2 2 cabal-install/1.20.0 77 cabal-install/1.20.0.0 157 cabal-install/1.20.0.1 408 cabal-install/1.20.0.2 4879 cabal-install/1.20.0.3 189 cabal-install/1.21.0.0 32 cabal-install/1.21.1.0 GHC 7.0 shipped with Cabal-1.10 (and so cabal-install-0.10 is the likely version used by GHC 7.0 users); so that should give you a hint about how many users didn't upgrade their cabal-install and stayed with cabal-install-0.10 (and probably GHC 7.0.x). So there are probably still a few users left on GHC 7.0... Otoh, it's nice to see that the latest cabal-install-1.20.0.3 (which uses a newer Cabal major version than is shipped with GHC 7.8) is being used the most for hitting Hackage -- seems the cabal-install "there's a newer version"-reminder is working quite well... Cheers, hvr

Ganesh Sittampalam

11 Sep 11 Sep

4:38 p.m.

On 09/09/2014 08:53, Herbert Valerio Riedel wrote:

...

GHC 7.0 shipped with Cabal-1.10 (and so cabal-install-0.10 is the likely version used by GHC 7.0 users); so that should give you a hint about how many users didn't upgrade their cabal-install and stayed with cabal-install-0.10 (and probably GHC 7.0.x). So there are probably still a few users left on GHC 7.0...

Thanks a lot for the analysis! I think I'll keep 7.0 support around for now and review it after there's a Haskell Platform with GHC 7.10. Cheers, Ganesh

3905

Age (days ago)

3914

Last active (days ago)

List overview

Download

13 comments

6 participants

participants (6)

Andreas Abel
Carter Schonwald
Ganesh Sittampalam
Greg Weber
Herbert Valerio Riedel
Johan Tibell