Nicolas Berthier

> It will be quite beneficial if we use the x86 MSYS2 version for testing an old JDK (version 8). > > Can you please try to put a cached...

> That's an interesting doc and we may should reset the JAVA_HOME to the 21 one for all other Windows environments then. *cf* #173

@ddeclerck @GitMensch Some Windows workflows appear to hang during tests (but not always). Do you know if that's an "expected" state of affairs?

https://github.com/OCamlPro/gnucobol/actions/runs/10522831045/job/29156289216?pr=170#step:8:3908 `-pedantic -std=c89` was a bit bold; won't be fixed in this PR though.

> Note that GnuCOBOL generated _functions_ can easily get > 100.000 LOC, so this may raise additional compatibility issues with generated sources on ancient environments. Slipping in a `s/\n\([^#]\)/\1/g` (sort...

@GitMensch Note: it appears that https://www.itl.nist.gov/div897/ctg/suites/newcob.val.Z is now an invalid link redirected to a generic web-page). I've changed the workflows for GC3 to use the `tar.gz` that's on sourceforge, but...

> The CI should have no download, only the cache of newcob.val - "make test" will do the download and unpacking as needed, using multiple URLs if necessary. The issue...

> > > The CI should have no download, only the cache of newcob.val - "make test" will do the download and unpacking as needed, using multiple URLs if necessary....

Ouch https://github.com/OCamlPro/gnucobol/actions/runs/10595691899/job/29362006666?pr=170#step:14:22 @ddeclerck @GitMensch would you have any idea how to solve that kind of issue? (it's MSYS2)

I agree the purpose of this repository is mainly about branch `gcos4gnucobol-3.x`. @lefessan do you think protecting branches `master` and `gnucobol-3.x` would break your mechanics for importing upstream branches?