Version 0.22.0

[tmigot]

Release notes:

Breaking changes

• drop support for Julia 1.6
• objcons! with in-place residual not defined for NLS
• the jac_lin* functions no longer take an x argument.

[tmigot]

Related to #520 #514

[github-actions]

Package name	latest	stable
ADNLPModels
AdaptiveRegularization
AmplNLReader
BundleAdjustmentModels
CUTEst
CaNNOLeS
DCISolver
FletcherPenaltySolver
FluxNLPModels
JSOSolvers
JSOSuite
LLSModels
ManualNLPModels
NLPModelsIpopt
NLPModelsJuMP
NLPModelsKnitro
NLPModelsModifiers
NLPModelsTest
NLSProblems
PDENLPModels
PartiallySeparableNLPModels
PartiallySeparableSolvers
Percival
QuadraticModels
RegularizedProblems
SolverBenchmark
SolverCore
SolverTest
SolverTools

[amontoison]

@tmigot You deprecated the old API or is it full breaking?
Honestly we didn't need to do this breaking change...
It is a lot of work to update all packages and it is not critical.
You should have asked before doing a breaking release...

[amontoison]

@frapac We will have more issues with the linear API.

[amontoison]

@tmigot @dpo
Who will update all the packages that depends on NLPModels.jl in the JSO organization now?

We can't do a breaking release for just an argument in the linear API...
So much work to update all packages and do new releases of dependent packages.

[dpo]

I've been trying to understand the situation here. If I understand well, no package in JSO currently depends on breaking release 0.22 of NLPModels. So nothing is effectively broken as long we don't merge CompatHelper PRs.

I propose that we do not bump the dependency of any package (inside our outside jSO) on NLPModels yet. Instead, we should fix what's broken with @deprecate and perhaps a little code around it to resolve ambiguities. The best is probably to open a new issue where we can discuss the details.

As a side note, not that many packages depend on the jac_lin methods: https://github.com/search?q=org%3AJuliaSmoothOptimizers+jac_lin+language%3AJulia&type=code&l=Julia.

In the future, we should leave PRs that will result in a breaking release open for several days before merging to give everyone a chance to chime in.

[amontoison]

As a side note, not that many packages depend on the jac_lin methods: https://github.com/search?q=org%3AJuliaSmoothOptimizers+jac_lin+language%3AJulia&type=code&l=Julia.

The issue is that we need to update the compat entries of dependent packages AND make a new release.
If a package doesn’t support version 0.22, it forces a downgrade of all packages that depend on NLPModels.jl.
In any case, making a breaking release is always a significant amount of work.

The last time I did one for Krylov.jl, I took responsibility for updating all dependent packages in the ecosystem. I made sure to do it in a way that allowed new features and bug fixes to continue landing smoothly in those packages. NLPModels.jl is a core component, and given the limited number of maintainers, we can't easily afford the cost of a breaking release.

In the current situation, since I only need a few non-breaking changes (a new boolean linear_api in NLPModelsMeta, as well as booleans indicating whether operators like jprod, jtprod, hprod, etc. are available),
I will add the commit on top of release 0.21.5 and continue the 0.21.x series of releases.

In the future, we should leave PRs that will result in a breaking release open for several days before merging to give everyone a chance to chime in.

👍 👍
I suggest to yank the current release 0.22 in the general registry.
Example: https://github.com/JuliaRegistries/General/blob/08bd4699b33ac03f159edb00f9926cdd59423df7/jll/C/CUDA_SDK_jll/Versions.toml#L102

[dpo]

I will add the commit on top of release 0.21.5 and continue the 0.21.x series of releases.

that would complicate things down the line because those commits will later have to be ported to 0.22. In the future, we must be more careful with breaking releases (in any package) but at the moment, the best course of action is to properly deprecate the old API and release 0.22.1.

[amontoison]

Yes, but it will take weeks or months until release 0.22 lands in all packages.
If we yank release 0.22, we remove it from the registry, and we can fix the current branch main so it's no longer breaking, and continue with version 0.21.6 instead of 0.22.1.
Releasing 0.22.1 will not fix anything, we will still need to update the compatibility entries of 30-40 packages and make new releases for all of them.

[dpo]

No, just the 4 or 5 that use the linear api explicitly. The rest can upgrade at a later time. I think @tmigot is working on a fix now.

[amontoison]

No Dominique, we can't have new features of minor modifications until we update the packages for 0.22.
We already got this issue in the past. I really don't want that it happens again (except if it is critical for the JSO ecosystem).

[dpo]

I completely understand and agree that nobody wants this kind of trouble. But the offending commits are already in main, so any future release will also contain them.

[amontoison]

It is not an issue if we yank the release 0.22 in the general registry, Dominique :-)
We do that quite often for the JLL.
We can add new commits on main to make the previous ones non-breaking and then continue the series of release 0.21.x.

If one day we really need a breaking release, we will tag 0.22.1.