Yes, that’s true, I agree KrylovKit could make VectorInterface part of it’s public API, which would change things. In that case I agree you could avoid the direct dep. However, I don’t think it will actually shield you from very much complexity, since if VectorInterface changes its api or functionality, that will force KrylovKit to change its api or functionality, and you will be exposed to the change anyway.
Also, for compat bounds, I think they can be not-too-hard to maintain following a few simple steps:
- set the compat bound to whatever version you are currently using and testing. You can do
] st -m VectorInterfaceto see that version, then just doVectorInterface = "0.5"or whatever it is. That will declare your package as compatible withv0.5and any version semver-compatible with that (sov0.5.1etc). - if VectorInterface has a breaking release (i.e. v0.5 to v0.6 or v1 to v2), check the release notes, update your compat bound to the new version, and test your package still works. Once you have your package updated, make a new release.
Of course it can be more of a headache than that (maybe some dependency hasn’t updated yet, maybe you want to try to support both versions for some reason, etc). But I think these simple rules can make managing compatibility easier, even if you don’t know a ton about the package.