Compatibility Management openfhe_julia - OpenFHE

[Tom-Finke]

A specific build of openfhe_julia is compatible with a specific range of OpenFHE, because they might introduce breaking changes with each release, even on the patch level.
Currently, we manage compatibility between the two in Project.toml.
Additionally, we set a compatibility in openfhe_julia in the Yggdrasil Recipe which ends up in the Binary Wrapper and the General Registry.
This has the potential to result in conflicting compats and is not very elegant. For simplicity reasons, we also restricts openfhe_julia to one specific version instead of a range.

Instead of adding OpenFHE as a dependency in OpenFHE.jl, could we not add only openfhe_julia, which pulls OpenFHE automatically as its own dependency, and manage comatibility with OpenFHE only in openfhe_julia via the Yggdrasil recipe?

• Manage compat with OpenFHE in openfhe_julia
• Release new openfhe_julia breaking release (minor relase while in major 0, else major release). when OpenFHE has breaking changes
• Manage compat with OpenFHE_julia in OpenFHE.jl, not giving a specific version but a regular lower bound

[sloede]

Instead of adding OpenFHE as a dependency in OpenFHE.jl, could we not add only openfhe_julia

No. This is considered bad style, and I know it breaks a few assumptions about how the Julia pkg ecosystem works (though I don't recall them in detail).

I don't know how other CxxWrap.jl users handle this - maybe we can ask. But relying on a indirect dependency I would not consider a suitable solution for this issue (though I share your annoyance with the inelegant approach we seem to be stuck with!)

[Tom-Finke]

• Singular.jl has a compat against both libsingular_jll and Singular_jll in its Project.toml, while libsingular_jll also sets Singular_jll as a dependency but without a compat entry in build_tarballs.jl. They say it gives them "flexibility in the development setup". This is similar to our setup, but we do set a compat for OpenFHE_jll in openfhe_julia_jlls build_tarballs.jl. But Singular.jl actually directly imports Singular_jll, which differs from OpenFHE.jl which does not directly import OpenFHE_jll.
• QML.jl only lists jlqml_jll in its [deps], while jlqml_jll has a Dependency with compat against Qt6Declarative_jll set in build_tarballs.jl. This is the approach I was suggesting, but I am not sure if it directly translates.