Question/recommendation about versioning

[f0uriest]

I noticed that equinox doesn't pin a maximum version of JAX. On the one hand I get why, since both are nominally alpha/eta/v0.x so compatibility is always kind of a crapshoot, but on the other hand both are widely used in the sci-comp/ML community and so I've run into issues in downstream packages of the form:

• JAX puts out a new release that breaks with the most recent version of equinox
• Downstream packages CI will pull the latest version of both packages, even though they're incompatible because pip etc doesn't see any conflicts, causing CI to fail in downstream packages due to issues between JAX/equinox
• Downstream packages have to either wait for a fix and new release, or do their own hacky patching of requirements to ensure that only compatible versions get installed.

I'd like to propose starting to add maximum tested versions to equinox's dependencies (and ideally also to lineax/optimistix/diffrax etc) to avoid these issues. This is a more conservative approach but would make packages that rely on the equinox ecosystem a lot more stable. People who always want the cutting edge can still of course manually install the latest version of everything, but for things we want to "just work" this lets the package manager figure things out appropriately.

[patrick-kidger]

Ah, I've been down this road before (on other projects). The problem with this is when a newly-released version of (in this case) JAX really is compatible, that this new version is needed for some other reason... and that many people's build systems are not sufficiently flexible to allow for manually overriding a too-strict constraint.

Conversely:

• most people's build systems are sufficiently flexible to add a new constraint, i.e. constraining JAX until an updated Equinox comes out with compatibility.
• downstream users who need to be robust to potentially-breaking new releases can just use a lockfile in their CI systems (which I think is a well-established best practice anyway).
• ...and it's actually really useful to me when these breaks do occur downstream, because then someone comes here and opens an issue/PR to let us know!

Happy to hear a rebuttal otherwise, but I'm afraid I'm inclined against this one for the reasons above. :)

[lockwo]

...and it's actually really useful to me when these breaks do occur downstream, because then someone comes here and opens an issue/PR to let us know!

With respect to this point, couldn't this also be solved with daily tests? I have it setup to run all tests every day, so any time something breaks (even if things are not being actively developed) it immediately is alerted. Seems like equinox/diffrax/etc. could also have that and catch things (in case the libraries that build on them miss it). Additionally this could be useful because sometimes there are issues that only come up in tests/typing/things that aren't caught in other builds (e.g. this commit patrick-kidger/diffrax@a5820a2 fixed an issue that wasn't a breaking change in any downstream libraries, but was breaking for anyone running adding on to diffrax since it now failed the diffrax testing).

[patrick-kidger]

Haha, I mean specifically in issues that only occur downstream -- from some intersection of cases not covered by existing tests.

This is the same relationship Diffrax etc have with JAX itself, for example: when a new release comes out we're often the ones testing some unusual intersection of JAX features, and I go upstream to report what's happened :)

(But separately yes, it would be totally fine to run the Diffrax etc tests on a cronjob, although as a practical matter I think the one you've highlighted is maybe the only case I can think of where this really would have been useful; most breaking changes come through specifically version bumps to JAX, and I'm already aware of them anyway.)