Version 0.11

[mcabbott]

After JuliaRegistries/General#73304 we should probably tag changes as 0.11.

This PR just updates the version number. It drops Julia 1.0 to enable #599 without further surprises.

We may wish to include other things in 0.11:

• <= as in Violating assumptions about Dual comparisons #609
• isinteger and friends: Change == to ignore measure-zero branches #481 (comment)
• Any of this list: Change == to ignore measure-zero branches #481 (comment)

[mcabbott]

Test failure on 1.8 is a tolerance issue.

436
       ...auto-testing SpecialFunctions.bessely with 2 arguments
[437](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:440)
  ...testing Dual{TestTag(),Int64,3} and Dual{TestTag(),Dual{TestTag(),Int64,0},3}
[438](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:441)
Dual{Z,Int64,3} and Dual{Z,Dual{Z,Int64,0},3}: Test Failed at /home/runner/work/ForwardDiff.jl/ForwardDiff.jl/test/DualTest.jl:596
[439](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:442)
  Expression: ≈(partials(pq[i]), PARTIALS * Calculus.derivative((x->begin
[440](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:443)
                    (gamma_inc(a, x, ind...))[i]
[441](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:444)
                end), 1 + PRIMAL), rtol = tol)
[442](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:445)
   Evaluated: Partials(2.911603324688561e-7, 3.8821377662514144e-7, 2.911603324688561e-7) ≈ Partials(2.91160034554385e-7, 3.8821337940584666e-7, 2.91160034554385e-7) (rtol=1.0e-6)
[443](https://github.com/JuliaDiff/ForwardDiff.jl/actions/runs/3601997063/jobs/6068433780#step:6:446)
Stacktrace:

[devmotion]

I think before doing that (also since discussions and decisions might take some time) it would be useful to tag a non-breaking 0.10 release with #605. That is, I think it would be good to revert #481 on the master branch and not only yank the latest release. That would also allow us to include more non-breaking fixes and features in 0.10 that come up before this PR is merged.

In general, maybe it would be useful to backport bug fixes for some time to 0.10 once 0.11 is released due to the widespread use of 0.10 (sinilar to what we do in SpecialFunctions where currently bug fixes for version 2 are backported to 1).

[mcabbott]

I think better just to make a branch for backports to 0.10, and then cherry pick whatever commits desired onto that. That's ends up with the right graph of changes, right? The branching and tagging can be done before 0.11.

Reverting seems (in my experience) to lead to changes rotting quietly somewhere. There was already far too much fighting with tests & re-basing in 481.

[mcabbott]

There was already a release-0.3 branch from way back when, presumably for the same purpose. So now there's a new one:

https://github.com/JuliaDiff/ForwardDiff.jl/tree/release-0.10

Edit: and #614 moves one change.

[j-fu]

Would love to see #615 (I think it is not breaking though formally changes API, ymmv...).

[mcabbott]

#615 looks safe.

Something new we could consider for 0.11 is to use "package extensions" rather than directly loading so many other packages.

[mcabbott]

Merging since v0.10.34 is now tagged on release-0.10 branch, JuliaRegistries/General#73859 .

[j-fu]

As for the package extensions: IMHO ForwardDiff loading many packages is no problem (compared to other packages). And for at least 1.6 backward compatibility one would have to mimic them via Requires.jl, thus losing compat guarantees for the corresponding packages on those older versions AFAIK. So I think this would introduce brittleness into an otherwise rock stable (from my experience) package with not much additional value.

[mcabbott]

It could I think always load them on old versions (as now) rather than using Requires.