OpenMM pinning strategy for downstream packages

[jakirkham]

There is a healthy ecosystem of OpenMM dependent packages, which is great to see and a nice accomplishment (speaks to the usefulness of OpenMM)

Though an important consideration comes with this, which is how should packages downstream of OpenMM pin their OpenMM dependency

To help start this conversation off, what sort of stability guarantees does OpenMM provide? Is it following SemVer or something else?

Thanks in advance for your feedback! 🙏

[peastman]

It depends on whether they're written in Python or C/C++. For plugins or packages that invoke it through the C++ API, we don't make any guarantees about binary compatibilty. The safest thing is to require the specific version of OpenMM they were compiled against, although in practice other versions that differ only in the third digit almost always work. But you definitely shouldn't assume a version with a different second digit will work.

For packages that invoke it through the Python API, we try very hard to maintain compatibility indefinitely. It's not 100% guaranteed, but it's very rare for an API to change in a compatibility breaking way, and we try to give lots of warning by first deprecating it and then waiting at least one major version. So it's generally safe to just specify a minimum version. It should continue to work for a long time.