That file has to be modified indeed when the c++ API changes. And so this is a good thing to look out for.
These days, with the work related to Symbolic Shape (you have detailed updates at State of symbolic shapes branch - #9 by ezyang), we are actually updating a lot of these signatures to support SymInt.
We ensured that users don’t see the change and that this is not BC-breaking for them. But if you do things like string matching of the signatures, that might be a challenge.
I’m afraid there isn’t a great answer to the binary compatibility question though. The way it works with libs like torchvision that have similar issue is that nightly PT works with nightly torchvision and we release new versions at the same time.
We also pin the torchvision release (the the pip package dependency) to a very specific PT release so that if the user asks for a given version of torchvision, they will get a working version of PT alongside it.
And if a user wants a specific version of PT that is not a release, then they also have to build torchvision from source.
I think you could follow a similar process, there are messages in the #annoucement channel on slack when RC are happening for a new release. That should give you time to prepare a binary as well to release alongside the PT one.