In managing custom resources within the registry operator and helm charts, it's crucial to establish a version skew strategy that ensures compatibility and smooth upgrades. Currently, we face the challenge of defining a clear approach to managing versioning, particularly concerning potential breaking changes and the frequency of updates.
Considered Options
Incremental Breaking Changes: Under this approach, versioning follows a pattern such as vXalphaY, where changes in Y may introduce breaking changes between changes of X. For instance, v1alpha2 might introduce breaking changes compared to v1alpha, while v1beta2 could introduce breaking changes compared to v1beta1. This method allows for more flexibility in introducing breaking changes while still maintaining compatibility within a major version.
gantt
title Incremental Breaking Changes
dateFormat YYYY-MM-DD
section v1alpha1
feature Foo.Bar :crit, v1a1f1, 2030-01-01, 10d
fix Foo.Bar :v1a1x1, after v1a1f1, 4d
section v1alpha2
BREAKING feature Foo.Bar :crit, v1a2f1, after v1a1x1, 7d
feature Foo.Baz :v1a2f2, after v1a1x1, 4d
section v1alpha3
REFACTOR feature Foo.Bar :crit, v1a3f1, after v1a2f1, 7d
fix Foo.Baz :v1a3x1, after v1a2f2, 14d
section v1beta1
CHORE promote Foo to beta :crit, v1b1f1, after v1a3x1, 7d
fix Foo.Bar :v1b1x1, after v1b1f1, 3d
section v1beta2
BREAKING feature Foo.Bar :crit, v1b2f1, after v1b1x1, 4d
fix Foo.Baz :v1b2x1, after v1b2f1, 3d
feature Foo.Baz.Cux :v1b2f2, after v1b2f1, 8d
Milestone-based Versioning: Alternatively, we could adopt a milestone-based versioning strategy. In this approach, versions could be denoted as vXalphaY, where Y increments at each major milestone without necessarily introducing breaking changes. For instance, v1alpha1 might represent the initial alpha release of version 1, v1alpha2 could be the second alpha release, and so forth. On the other hand, vXbetaY versions could signify updates within a milestone, with Y incrementing at each update. However, no breaking changes would be allowed within the beta phase.
gantt
title Incremental Breaking Changes
dateFormat YYYY-MM-DD
section v1alpha1
feature Foo.Bar :crit, v1a1f1, 2030-01-01, 10d
fix Foo.Bar :v1a1x1, after v1a1f1, 4d
BREAKING feature Foo.Bar :v1a2f1, after v1a1x1, 7d
section v1alpha2
feature Foo.Baz :crit, v1a2f2, after v1a2f1, 4d
REFACTOR feature Foo.Bar :v1a2f2, after v1a2f1, 7d
fix Foo.Baz :v1a2x1, after v1a2f2, 14d
section v1beta1
CHORE promote Foo to beta :crit, v1b1f1, after v1a2x1, 7d
fix Foo.Bar :v1b1x1, after v1b1f1, 3d
section v1beta2
feature Foo.Baz.Cux :crit, v1b2f1, after v1b1x1, 8d
fix Foo.Baz :v1b2x1, after v1b1x1, 3d
Context and Problem Statement
In managing custom resources within the registry operator and helm charts, it's crucial to establish a version skew strategy that ensures compatibility and smooth upgrades. Currently, we face the challenge of defining a clear approach to managing versioning, particularly concerning potential breaking changes and the frequency of updates.
Considered Options
vXalphaY, where changes inYmay introduce breaking changes between changes ofX. For instance,v1alpha2might introduce breaking changes compared tov1alpha, whilev1beta2could introduce breaking changes compared tov1beta1. This method allows for more flexibility in introducing breaking changes while still maintaining compatibility within a major version.vXalphaY, whereYincrements at each major milestone without necessarily introducing breaking changes. For instance,v1alpha1might represent the initial alpha release of version 1,v1alpha2could be the second alpha release, and so forth. On the other hand,vXbetaYversions could signify updates within a milestone, withYincrementing at each update. However, no breaking changes would be allowed within the beta phase.