For 2.16: cabal file maintenance

Building with -fwarn-as-error succeeds and the test suite passes for all
supported compilers (on Linux).

4 patches for repository http://darcs.net/screened:

patch 9cba0372c14aca1f85636002502c585c84335405
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Aug  9 11:15:42 CEST 2020
  * relax upper bound for constraints to < 0.13

patch 55a71d2bcac2b1771738c5462f86c215e24109d6
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Aug  9 11:16:16 CEST 2020
  * relax upper bound for time to < 1.11

patch c2e38730ba7d6e6d4fe15101834c7dcceb3a2e79
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Aug  9 11:16:53 CEST 2020
  * relax upper bound for network-uri to < 2.8

patch 16a1d5612f2169997c0963c29c31553c70eb9887
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Aug  9 11:17:43 CEST 2020
  * relax upper bound for conduit to < 1.3.3

Attachments

• patch-preview.txt
• relax-upper-bound-for-constraints-to-_-0_13.dpatch
• unnamed

All fine with me. I'll test on Windows with the higher bounds but I don't
think we need to be too paranoid.

Were you able to find an install plan with time>=1.10 with the tests 
enabled?
I get a conflict with test-framework, which only supports <1.10:

https://hackage.haskell.org/package/test-framework

When testing bounds changes I explicitly use `--constraint 'foo>=n'` where n
is just below the new upper bound.

Never mind, I'd forgotten about --allow-newer 'test-framework:time'.

> Were you able to find an install plan with time>=1.10 with the tests 
> enabled?

Yes, definitely. I ran the full test suite for all supported compilers.
I have

> cat cabal.project.local
flags: +warn-as-error
tests: True

> I'd forgotten about --allow-newer 'test-framework:time'.
I needed no such tweaks.

Which ghc version did you use?

>> I'd forgotten about --allow-newer 'test-framework:time'.
> I needed no such tweaks.
> 
> Which ghc version did you use?

I tried 8.6.5 and 8.10.1, but it shouldn't make any difference.

If you look at test-framework on hackage, it just don't support time>=1.10.

> If you look at test-framework on hackage, it just don't support time>=1.10.

Ah, now I understand what you are saying. It makes no difference in the
sense that whether we allow newer time versions or not, the current
version of test-framework will force us to use time < 1.10 anyway.

So we cannot currently test with time >= 1.10. Thus we should not raise
the upper bound.

I have obliterated the patch taht raises the upper bound for time in
screened and reviewed.

>> If you look at test-framework on hackage, it just don't support time>=1.10.
> 
> Ah, now I understand what you are saying. It makes no difference in the
> sense that whether we allow newer time versions or not, the current
> version of test-framework will force us to use time < 1.10 anyway.
> 
> So we cannot currently test with time >= 1.10. Thus we should not raise
> the upper bound.
> 
> I have obliterated the patch taht raises the upper bound for time in
> screened and reviewed.

Well, we can test, with --allow-newer (and I did). So we can be sure
that as soon as test-framework raises its upper bound, darcs will work.
I would have left the patch in.