Release SpecialFunctions 2

[devmotion]

This PR bumps the version number to 2.0.0. A breaking release is required due to #297. I agree with @ararslan's comment that as long as there are no other breaking changes that are about to be merged and should be included in this breaking release we can just make a breaking release right away - all bugfixes and non-breaking changes in the master branch are already released.

Fixes #360.

[codecov]

Codecov Report

Merging #361 (4be86ea) into master (82ec8e2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #361   +/-   ##
=======================================
  Coverage   92.07%   92.07%           
=======================================
  Files          12       12           
  Lines        2790     2790           
=======================================
  Hits         2569     2569           
  Misses        221      221           

Flag	Coverage Δ
unittests	92.07% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/beta_inc.jl	92.41% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 82ec8e2...4be86ea. Read the comment docs.

[KristofferC]

It seems incredibly excessive to release a 2.0 based on this. The removed functionality doesn't seem to be really used either: #297 (comment). I really think this should be reverted! This package is not in the stage where you can make a few line change that is technically breaking and just release a 2.0. It needs much more care than that.

Look at this compat string from CompatHelper: JuliaDiff/ForwardDiff.jl#564. Please stop doing these micro-breaking stuff, it is incredibly disruptive to the ecosystem.

[devmotion]

Reverting the breaking change or releasing 2.0? I suggested making a non-breaking release in #360 (comment), due to the few downstream packages that would be affected and since I think maybe one could even view the removal of type piracy as a bugfix. However, this suggestion was not received well 🤷‍♂️

[KristofferC]

Yes, looking at the actual impact this would have had on the ecosystem and deciding if this was breaking in practice would have been correct. If it would have been breaking, the (one or two) packages that rely on it could have been fixed. This package has 300 dependencies that all need to do things now. 300 Compat PRs, 300 new registrations to General with all the ripple effects it has etc. Packages that are not actively maintained will be on releases that are unlikely to get bugfixes, etc.

[KristofferC]

Technically it is already too late to revert anything because I see CompatHelper PRs have rolled out and people might already declare compat on this 2.0 SpecialFunctions.