CompatHelper: bump compat for ExtendableFEMBase in [weakdeps] to 1, (keep existing compat)

[github-actions]

This pull request changes the compat entry for the ExtendableFEMBase package from 0.7,0.8 to 0.7,0.8, 1.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

[pjaap]

Since we spent some time to understand the CI failure:

ERROR: LoadError: Unsatisfiable requirements detected for package ForwardDiff [f6369f11]:
 ForwardDiff [f6369f11] log:
[...] restricted to versions 1 by an explicit requirement, leaving only versions: 1.0.0 - 1.0.1
[...]

We did not understand where the explicit requirement for 1 arises.
Answer: This is triggered by the force_latest_compatible_version=true that the CI test uses in Pkg.test.

There is a hint at the top of the test job:

[ Info: This is a Dependabot/CompatHelper job, so force_latest_compatible_version has been set to true

This tells the package resolver to use only the lastest compat, in case of multiple compats. For Forwarddiff, this is here "0.10.35, 1", and hence only 1 is considered. This version is incompatible to other dependencies.

This means we have an inactive compat ForwardDiff = 1 in the project.
Should we remove this, until it is compatible to the other dependencies?

[pjaap]

I thought about this again.

I think we should remove the ForwardDiff v1 compatibility. Nothing is ever tested with this version. We should let the CompatHelper open a PR with the version bump of ForwardDiff and leave it unmerged until CI with force_latest_compatible_version succeeds.

Thoughts?

[j-fu]

... I tend to disagree - if everyone does this, this might never move on.

There is one breaking change: https://github.com/JuliaDiff/ForwardDiff.jl?tab=readme-ov-file#upgrading-to-forwarddiffjl-10 . I never use "==" on dual numbers, so this should not result in problems in the library. However, users in their flux functions etc. may be tempted use this. So IMHO we should

• add a remark in the changelog hinting on this for the version where the compat has been upgraded

• run a subset of the tests in an experimental branch which disables some functionality (mainly sparsity detection which I want to move into an extension anyway for 3.0) and allows to resolve ForwardDiff to 1.0 in order to see what may be affected. EDIT: see DON'T MERGE! Run subset of tests with ForwardDiff 1.0 #197

[j-fu]

But wait a minute: why is force_latest_compatible_version=true here ? In the tests for 2.9.1 it is false, and all tests passed with ForwardDiff compat allowing for 1 . May be this is specific for CompatHelper PRs?
... Ah yes, it seems like that: JuliaRegistries/CompatHelper.jl#298

So I stand by my previous remark.

[pjaap]

Yes, CompatHelper does as stricter test than the usual CI. I think the reasons are clear, as it discovers a hidden problem.

Out of curiosity I like the idea to check on a experimental branch that "everything" is fine with ForwardDiff v1. However, "everything" is now just a subset of VoronoiFVM, as seen in the corresponding PR #197.

This is also not a sustainable solution in the long run.
Shouldn't we poke the OrdinaryDiffEq guys to raise their compat to ForwardDiff v1? There is no issue on that and I would simply open one.

Your argument "if everyone does this..." is not a good one. I could simply counter with "I everyone ignores test coverage then we don't need compats at all" 😉

I'll open a PR in the OrdinaryDiffEq repo and wait for the response.

[pjaap]

Ah, it is already in the works: SciML/OrdinaryDiffEq.jl#2643

[pjaap]

And there are discussions about this along several SciML projects. Most activity in the last two days.
So I think the ForwardDiff v1 breaking change has some severe consequences in the SciML world, since CI fails there in the CompatHelper jobs.

Therefore, I really vote to wait for this to be fixed and then integrate this in VoronoiFVM.

[j-fu]

Well, if they hit some problems with ForwardDiff v1.0 they won't release a version using this, and Pkg will resort to v0.10 for anyone using one of these packages. So I really think we could safely upgrade this.

[j-fu]

got stuck here, close this in favor of #205