Just wondering how such a use case could work. At least with our application suite we have a lot of dependency between different deployments and breaking changes do happen and we do run multiple major releases of versions.
I can see that versions are generated on the fly in a very fixed way e.g. v1, v2, v3 but how do you actually keep multiple versions up and injesting traffic where appropriate?
At the moment, Waypoint treats application version strings as basically opaque values used on deployment assets, like docker tags. It won’t help you manage the scenario you have here because it doesn’t have the concept of how those services are linked together according to version.
In a waypoint view, you could instead have all those apps defined in one waypoint.hcl that you deploy together. I realize for a large service constellation that won’t work, but if you have a smaller setup, it might.
I’ll add to what Evan said that we plan on supporting more complex release strategies and deployment strategies in future versions. You can see we laid some of the groundwork for that with the release configuration stanza. So what you’re describing is definitely in scope for the Waypoint project, but we aren’t there yet today beyond what Evan said.