Particular code changes might impact the exact release procedure (e.g. changing order, can't rollback one thing without the other, etc), and we want to make the life of a person doing the release as easy as possible
If there are changes to the compute image, there is no way to check we don't have old computes in the cluster
Feature idea(s) / DoD
All the mentioned problems are solved
Implementation ideas
Use the release version as a protocol version, and define compatibility with versions (scheduler==v0.27.0 is compatible with v0.25.0 <= autoscaler-agent >= v0.28.0
Write code in a backward-compatible way, meaning that componentA==v0.(x) always works with v0.(x-1)<=componentB<=v0.(x). We must analyze whether is there a practical rule of such class, so that custom deploy procedures are never needed.
Problem description / Motivation
The compatibility between different versions of different components is currently defined in https://github.com/neondatabase/autoscaling/blob/main/pkg/api/VERSIONING.md
We have a number of problems with it:
580 and #761 needs this info to work
Feature idea(s) / DoD
All the mentioned problems are solved
Implementation ideas