Change versioning to be Kubernetes compliant #4831
Description
Describe the current behavior
As first reported in #4147 and explored in the ADR Resources and Version Priority, the way we're defining our resource versions in ASO is not compliant with Kubernetes rules.
This failure results in Kubernetes' version priority rules consistently selecting the oldest version of any ASO resource.
This has resulted in confusion, and more importantly, to data loss for users as they work with their resources. (See ASO #4723, CAPZ #5168, and CAPZ #5649 for examples.)
Describe the improvement
We're going to change our versioning using v1api as a consistent prefix to just v.
| Old Version | New Version |
|---|---|
v1api20250701 |
v120250701 |
v1api20250201preview |
v20250201preview |
And so on.
This will, eventually, be a breaking change but we're going to try and make this as painless as possible by introducing the new versioning scheme alongside the old one (we'll support both v1api20250701 and v120250701 of the resource simultaneously) wherever possible.
Plan
For v2.15 get all the groundwork in place for the upgrade to occur.
From v2.16:
- All new resources get new style versions
- Migrate group by group, including all tests and samples
- All resources that existed prior to v2.16 continue to work
Post migration - sometime after v2.20 - we'll remove the old versions.
TODO
- Work out which resources are too big to migrate this way, and what to do instead