For discussion for now (and also whether it should
go to the 2.18 branch)

Arguably we could also drop a bunch more older versions.

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch 55b2c5f9a3b35bd89276a2c80530dcd62c6da71d
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:10:46 BST 2024
  * drop support for GHC 8.2

  It's ancient and we're not testing it on CI

Attachments

• drop-support-for-ghc-8_2.dpatch
• patch-preview.txt

I've said it in the past and my policy hasn't changed on this:

I am not opposed to dropping support for older GHC versions as soon as it 
gets us any concrete benefit. Like, using a new feature not available in some 
old version. Or avoiding extra conditionals in the cabal file or CPP in some 
module. Really, anything that allows us to simplify our code or reduce 
maintenance cost.

But I am strictly against throwing out support for old GHC versions 
proactively without any such benefit in sight.

BTW, I do regularly build and test with ghc-8.2 on Linux and so far this 
hasn't been a problem at all.

Sorry, I probably forget your position after a while so the
cycle starts again!

In fact dropping 8.2 does allow us to drop one bit of CPP -
see amended version of the patch.

Searching the codebase, bumping to GHC 8.8 (base 4.13) would allow
us to drop quite a bit more.

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch 3e53c4944a8221dc58d2ad4049ef4fe7edd55778
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun  3 08:28:49 BST 2024
  * drop support for GHC 8.2

  It's ancient and we're not testing it on CI

Attachments

• drop-support-for-ghc-8_2.dpatch
• patch-preview.txt

Having said all that, I just grepped for MIN_VERSION_base which gives me the 
following:

src/Darcs/Util/Regex.hs:#if !MIN_VERSION_base(4,13,0)
src/Darcs/Util/Regex.hs:#if MIN_VERSION_base(4,13,0)
src/Darcs/Prelude.hs:#if MIN_VERSION_base(4,11,0)
harness/Darcs/Test/Patch/Examples/Unwind.hs:#if MIN_VERSION_base(4,12,0) && 
!MIN_VERSION_base(4,13,0)
harness/Darcs/Test/Patch/Examples/Unwind.hs:#if MIN_VERSION_base(4,12,0)

I would disregard the one in src/Darcs/Prelude.hs, but for the other two 
files it would be nice to get rid of the extra CPP. For 
src/Darcs/Util/Regex.hs this would mean ghc >= 8.8, for 
harness/Darcs/Test/Patch/Examples/Unwind.hs it means ghc >= 8.6.

> Having said all that, I just grepped for MIN_VERSION_base which gives me 
> the following:

Right - and there's a bunch of examples in the imported shelly code,
though maybe we want to minimise the divergence from "upstream" there?
I'm not sure if we ever plan to reconverge or maybe instead would
be looking to merge it into our own code or replace it.

Seems we sent our messages in parallel. I don't think the single 
conditional in Darcs.Prelude is worth dropping support for ghc-8.2, 
given that Darcs.Prelude is something we touch only to ensure 
compatibility.

Weighing the advantages and disadvantages, my proposal would be to 
postpone this move until we are ready to drop support for ghc-8.6.

The shelly code also has MIN_VERSION_base(4,13,0), so we'd have to 
require ghc >= 8.8 to get rid of that.

And no, I don't think we will ever merge with the original shelly 
package. Our fork was from a rather old release when they broke our code 
on Windows; back then I wasn't able to figure out what exactly caused 
the problem and they never reacted to any of our bug reports. Later on I 
fixed lots of warnings in our copy, dropped modules we don't need, and 
integrated the remaining ones into the test harness (no longer treating 
it as a package). Ideally we could rely on some other package with 
similar functionality, but my attempts so far haven't been successful. 
Shelly seems to be the only one that maintains a separate environment 
(including CWD) for sub processes, which is something the test suite 
relies on.

here's a followup showing the level of cleanup including
shelly if we also dropped GHC 8.4 and 8.6

The GLASGOW_HASKELL related stuff is truly ancient (refers
to GHC 7.6) so could be dropped regardless.

Most of this is code we don't touch that much so I don't
know how much real benefit there is though. I think the main
advantage is that when we do come across the code, we don't
then have to re-think the whole GHC version support question.

2 patches for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch 3e53c4944a8221dc58d2ad4049ef4fe7edd55778
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun  3 08:28:49 BST 2024
  * drop support for GHC 8.2

  It's ancient and we're not testing it on CI

patch d6d93a261e943e60c9cbb3d51d6211128d33907e
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun  3 09:38:21 BST 2024
  * drop GHC 8.4 and 8.6 support

Attachments

• drop-support-for-ghc-8_2.dpatch
• patch-preview.txt

Hmm. Can we agree on throwing out the ancient GLASGOW_HASKELL stuff as a 
separate patch? I think I saw some of those in other places, too, also 
for GHC versions in the 7.x range.

As for the larger ghc version drop: I was hoping to keep support at 
least ghc-8.6 a bit longer, but it seems the 8.6 to 8.8 step was the the 
one that introduced most of the incompatibilities. Suppose we go all the 
way, what about new releases on branch-2.18? Do we aim for keeping the 
older GHC versions supported there or do we rather want to support newer 
ones? Note that when we drop ghc <= 8.6 from screened, we no longer 
regularly test them, so pulling patches into branch-2.18 could prove to 
be be difficult.

The other place was in tests/issue2333.sh which has 'require_ghc 706'.

What I meant with "could prove difficult" is that (if we we keep 
supporting the older ghc there) we have to be careful to run the CI on 
the branch before publishing new releases, and possibly remove the -
fwarn-as-error in the CI configuration.

I've sent patch2406 separately for the GLASGOW_HASKELL cleanups

I've consolidated the changes on top of patch2406

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch d88d94a04caa1c0cec17a65e3e1e9b92359ace17
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun  3 21:54:48 BST 2024
  * move minimum supported GHC up to 8.8

Attachments

• move-minimum-supported-ghc-up-to-8_8.dpatch
• patch-preview.txt