search

JuliaMath / NaNMath.jl

Julia math built-ins which return NaN and accumulator functions which ignore NaN
Other
53 stars 28 forks source link

Incorrectly tagged breaking change #59

Closed LilithHafner closed 2 years ago

LilithHafner commented 2 years ago

I think that tagging this as a breaking change was a mistake because it is impossible for dropping a Julia version to result in broken code. c.f. https://github.com/SciML/ColPrac#dropping-support-for-earlier-versions-of-julia.

This is a problem because NaNMath has a lot of dependants and they now need to update their compact entries for NaNMath if they wish to receive future updates (e.g. the changes made in v1.0.1).

One possible resolution would be to yank 1.0.0 and 1.0.1 from the registry and tag master as 0.3.8, the next breaking change could then be tagged as either 0.4.0 or 2.0.0.

Another possible resolution would be to update every package that depends on NaNMath to declare compatibility with 1.0.0. Concretely, I am aware of 35 packages that depend on NaN math, 13 of which do not declare compatibility with v1.0.1:

StaticOptim
ClimateTools
Winston
HetaSimulator
HyperDualNumbers
RvSpectMLBase
GraphRecipes
YAAD
EAGO
ReverseDiffSparse
McCormick
LineSearches
RvSpectML

Resolution 1 requires fewer changes (there is no need to change the 22 registered packages that already declared support for NaNMath v1 or the 13 packages that do declare support for v1) and eliminates an erroneous breaking change.

Resolution 2 lets this package keep the visually appealing 1.x version numbers.

cc @mlubin

mlubin commented 2 years ago

I have to respectfully disagree that tagging a 1.0 release of a package is a "mistake" if there are no breaking changes. 1.0 defines the public API (https://semver.org/) and is good for the Julia ecosystem, see various discussions: https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124 https://discourse.julialang.org/t/getting-to-1-0-how-can-we-get-packages-to-make-that-tag/59608

Packages that depend on NaNMath should update their compatibility if they want new releases, it's very easy to do.

LilithHafner commented 2 years ago

It is certainly not a clearcut issue, but I agree with @KristofferC's comments from one of the discussions you linked. The primary purpose of these versions is to support automatic compatibility analysis, not a commitment to maintenance.

Documentation defines the public API, not the release of 1.0. And the Julia package manager uses a modified version of SymVer that attributes semantic meaning to pre-1.0 versions as well.

The reason I'm bringing this up here is because this package has an out of date version that is widely used while I imagine the latest version is appropriate for the vast majority of users. For example, OrdinaryDiffEq is a reasonably popular end user package that indirectly depends on an out of date version of NaNMath.

I could certainly make those 13 PRs, but it feels like a roundabout way of dealing with this.

As an aside, It would be lovely if there were a better way to signify "no more breaking changes for a while" without simultaneously saying "here's a breaking change".

LilithHafner commented 2 years ago

From @StefanKarpinski on discourse

This is what I’d recommend and what I’ve done myself with the handful of packages I maintain: bite the bullet and go to 1.0 when it seems ready and adjust anything that has compat bounds that include the last version to also include 1.0.

mlubin commented 2 years ago

I opened PRs on a handful of the packages you listed. About half of the 13 are either unmaintained packages or already have the correct compat bounds and just haven't tagged a release.