As I’m working on a new interface protocol, I’m remembering the headaches I’ve had in the past when trying to refactor the protocol (key / value pairs, not the code API in front of it) due to bugs, new features on the interface (e.g., moving from single to multiple requests), or wanting to use new Juju features (e.g., app relation data) while still retaining backward compatibility and also trying to not make the code a mess. Because both sides of the relation might have different levels of support, you also have to take in to account differences on both ends. I’ve repeatedly found myself wishing the original author of the interface protocol had the foresight to include an API version in the relation data and that we had a good pattern to follow for negotiating a commonly understood version to be able to talk.
I’d really like to see something like this built into the framework, even if it’s just a set of helpers that we strongly encourage developers to use. I generally like the way the Juju controller & client handle Facade versions and would like to see a pattern like that made easy to use with charm interfaces, but that does require that both sides be aware of the version negotiation from the start, and a lot of existing interfaces may want to “upgrade” to a versioned pattern but still have to support charms built against the unversioned protocol.
For now, at least, I’m going to ensure that my new interface protocols include and block on a version number in the app-level relation data.
Thoughts? Any existing patterns or plans that I’m not aware of?