The current registry operator release process can be found here. This needs to be edited to reflect the new process that is going to take place to ensure the automation of this process functions properly. Currently we are creating release branches for a major release, such as release-v0, release-v1, release-v2, where all minor and patch releases would be contained within those for their respective major. For example v0.1.1 would have its source code a part of release-v0.
This naming convention is causing issues with our release automation because the release is initially based off of main and the release branches and main have diverged git histories. In order to solve this problem entirely it has been decided that each release will get its own branch.
An example would be as follows:
v1.0.0 is to be cut -> v1.0.0 branch is created based off main -> v1.0.0 tag on git
When it is time to cut a new minor for v1 we would create a v1.1.0 branch based off main and tag accordingly.
For backporting we would need to cherry-pick commits from main and create a release branch for each version we want to backport to. For example if we had v1.0.0 and v1.1.0 branches and wanted to backport a change, we would create v1.0.1 and v1.1.1.
Acceptance Criteria
[ ] Documentation is updated to reflect new process
Which area/kind this issue is related to?
/area registry /area documentation
Issue Description
The current registry operator release process can be found here. This needs to be edited to reflect the new process that is going to take place to ensure the automation of this process functions properly. Currently we are creating release branches for a major release, such as
release-v0,release-v1,release-v2, where all minor and patch releases would be contained within those for their respective major. For examplev0.1.1would have its source code a part ofrelease-v0.This naming convention is causing issues with our release automation because the release is initially based off of
mainand the release branches andmainhave diverged git histories. In order to solve this problem entirely it has been decided that each release will get its own branch.An example would be as follows:
v1.0.0is to be cut ->v1.0.0branch is created based offmain->v1.0.0tag on gitWhen it is time to cut a new minor for
v1we would create av1.1.0branch based offmainand tag accordingly.For backporting we would need to cherry-pick commits from
mainand create a release branch for each version we want to backport to. For example if we hadv1.0.0andv1.1.0branches and wanted to backport a change, we would createv1.0.1andv1.1.1.Acceptance Criteria