Pin jll version?

[evetion]

This came up at the recent Munster workshop. We really cant mix non-semver versions into a semver ecosystem (and still say we have stick to semver in any packages with non-semver deps).

I came out of that strongly in favour of locking down our binary deps like this wherever they hit a package with real semver.

What we have with semver and hard upper bounds is truly amazing compared to Python/R ecosystems, and we should lean into it even more.

Instead of reverting the ~, we can add it to all the previous versions in the registry?

Originally posted by @rafaqz in #24 (comment). Also see the other comments there.

[visr]

Have you seen any indication that libspatialindex doesn't stick to semver?

[rafaqz]

But that the right question?

I more inclined assume that any version system that isn't explicitly using semver, can break semver. I cant find any mention of it in their docs either.

I don't think we can claim to follow semver here either if we don't pin the version.

[evetion]

Have you seen any indication that libspatialindex doesn't stick to semver?

Do you have an indication that they do? I don't think you can assume semver to be the default.

But I'd say that doesn't matter. The point is, you can't know what changes from upgrading the jll on Ygdrasil. Maybe they do semver and just fixed a bug, but it still breaks our downstream code. Their semver contract is different (changes on a mailinglist?) from ours in the Julia ecosystem (covering our tests?).

Besides, I think a single user encountering a breaking jll is worse than the developer experience of updating the a compat bound here, or not getting direct updates. CompatHelper (does it work for jll?) should help us here as well.

[visr]

I'm fine with pinning the version, it does give more reassurance we don't accidentally end up in a broken state, given that we don't have reverse tests in Yggdrasil yet.

Please watch https://github.com/JuliaBinaryWrappers/LibSpatialIndex_jll.jl though so new releases are noticed by maintainers, since CompatHelper won't bump the minor version for us (I think?), and the JLL can be upgraded by others that won't necessarily know to update the compat here as well.

This JLL is a very simple case since the JLL has neither dependencies nor dependents. I assume you'd like to do this for all JuliaGeo wrapper packages? Don't forget to update the General registry as well, possibly you can use https://github.com/JuliaRegistries/RetroCap.jl. I'd check in the Slack thread first if the General maintainers would be fine with this.