We require all teams to use semver and usually define the Conjure API in the same repo as the server that implements it (so they are versioned together). Most of the time teams want to preserve wire-format back compat (i.e. only add optional fields to requests and don’t remove things from responses). Devs are pretty good at this, but we actually run a conjure-backcompat checker as part of CI to catch any unintended breaks they might have missed.
When it comes to intentional breaks, teams save up a bunch of carefully documented changes and then tag the next semver major version (i.e. 2.0.0). This is safe to do because all microservices and frontends we build actually contain embedded minimum and maximum version constraints on the backend services they require. Our deployment infrastructure knows about all these constraints and can then ensure that new major releases will only be rolled out in production when all their callers have explicitly declared support.
The deployment infra constraints mentioned in parent post are generally managed by tooling we also publish[1]. The encoding ends up similar to Helm’s, but happens through this tooling just by virtue of taking a dependency on a published jar, npm package or conda package, and that removes a lot of programmer error/guess work/maintenance. (I think we’d be open to also emitting Helm’s formats in our packaging tools, if that’s interesting to someone reading this feel free to open an issue on our repo and reference my post.)
When it comes to intentional breaks, teams save up a bunch of carefully documented changes and then tag the next semver major version (i.e. 2.0.0). This is safe to do because all microservices and frontends we build actually contain embedded minimum and maximum version constraints on the backend services they require. Our deployment infrastructure knows about all these constraints and can then ensure that new major releases will only be rolled out in production when all their callers have explicitly declared support.