Release management #555

nilekhc · 2021-05-18T22:42:01Z

What this PR does / why we need it:

Defines Release Management guidelines.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #541

Special notes for your reviewer:

Signed-off-by: Nilekh Chaudhari <1626598+nilekhc@users.noreply.github.com>

k8s-ci-robot · 2021-05-18T22:42:09Z

Hi @nilekhc. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

nilekhc · 2021-05-18T22:43:25Z

/assign @sozercan
/assign @tam7t

k8s-ci-robot · 2021-05-18T22:43:26Z

@nilekhc: GitHub didn't allow me to assign the following users: sozercan.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @sozercan
/assign @tam7t

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot · 2021-05-18T22:46:15Z

@nilekhc: GitHub didn't allow me to assign the following users: sozercan.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @sozercan

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

nilekhc · 2021-05-19T17:44:18Z

/cc @tam7t

aramase · 2021-05-19T19:07:51Z

/label tide/merge-method-squash
/kind documentation

tam7t · 2021-05-24T17:26:16Z

docs/Release_Management.md

+
+- A new release should be created on the _`second Wednesday`_ of each month. This schedule not only allows us to do bug fixes, but also provides an opportunity to address underline image vulnerabilities etc. if any.
+
+- Once the new version is decided(as per above guideline), release candidate branch should be created from `master` with name `vX.Y.Z-rc.W` followed by release with same tag, for eg. if new version is going to be `v0.1.2` then release candidate branch should be `v0.1.2-rc.0`


there's some discrepancies between this and our current release docs:

https://github.com/kubernetes-sigs/secrets-store-csi-driver/blob/master/docs/RELEASE.md#building-and-releasing

we use release-<VERSION> for the branch names (no rc's)

@aramase do you think this or the release docs should be updated? Should we also create long lived release branches?

I think we should create long live release branches as part of v0.1.0. This could be the 1st release that we can explore options to cherry pick bug fixes and cut patch releases.

Note: we'll also need to track pipeline changes to handle these scenarios of building from release branches.

As for the release branches, I don't think we need release branches for rc. We cut a release branch for the intended release release-v0.1.0. RC images will be published from the master branch with tags. After rc image validation, we'll build cut a stable release branch and build the image from the release branch. WDYT?

This is how kubernetes does it today

that sgtm, and also the merging to master + cherry picking to release branches

tam7t · 2021-05-24T17:35:06Z

docs/Release_Management.md

+### Minor releases
+- Minor releases contain security and bug fixes as well as _**new features**_.
+
+- They are backwards compatible.


Are we committing to backwards compatible within the Major release?

Does backwards compatible imply upgrade path or just features?

I'm not sure that we would want to commit to backwards compatibility until v1 Major release and within a Major release I'm not sure we want to support arbitrary upgrades.

example:

Should 0.2.0 be backwards compatible in features with 0.1.0

Should a direct upgrade from 1.1.0 to 1.3.0 be possible or may you need to go through 1.1.0 -> 1.2.0 -> 1.3.0 (from the test gate section above i assume that the user would need to step through each minor release)

I think major release should imply breaking change. For eg if we go from 1.0.0 -> 2.0.0 then we indicate there is breaking change and not all features would work as expected.

Also, backward compatibility I am thinking in terms of features and not upgrade path.

Should 0.2.0 be backwards compatible in features with 0.1.0

This is correct

Should a direct upgrade from 1.1.0 to 1.3.0 be possible or may you need to go through 1.1.0 -> 1.2.0 -> 1.3.0 (from the test gate section above i assume that the user would need to step through each minor release)

I think it should be possible to go from 1.1.0 -> 1.3.0. I don't believe we have any such restriction today. (Please correct me if I am wrong here)

As for backward compatibility we can document since which version/release we can support. WDYT?

ACK, I'm not sure its feasible for us to maintain and test all permutations of up update paths, so maybe just adding some wording that upgrades are only tested for consecutive version numbers

@tam7t / @aramase Do we do any upgrade test for driver?

Since you're working on #457 - yes we intend to so this sgtm

docs/Release_Management.md

aramase · 2021-06-07T18:28:32Z

docs/Release_Management.md

+
+- A new release should be created on the _`second Wednesday`_ of each month. This schedule not only allows us to do bug fixes, but also provides an opportunity to address underline image vulnerabilities etc. if any.
+
+- Once the new version is decided(as per above guideline), release candidate branch should be created from `master` with name `vX.Y.Z-rc.W` followed by release with same tag, for eg. if new version is going to be `v0.1.2` then release candidate branch should be `v0.1.2-rc.0`


I think we should create long live release branches as part of v0.1.0. This could be the 1st release that we can explore options to cherry pick bug fixes and cut patch releases.

Note: we'll also need to track pipeline changes to handle these scenarios of building from release branches.

As for the release branches, I don't think we need release branches for rc. We cut a release branch for the intended release release-v0.1.0. RC images will be published from the master branch with tags. After rc image validation, we'll build cut a stable release branch and build the image from the release branch. WDYT?

This is how kubernetes does it today

aramase · 2021-06-07T18:32:17Z

docs/Release_Management.md

+
+- Once the new version is decided(as per above guideline), release candidate branch should be created from `master` with name `vX.Y.Z-rc.W` followed by release with same tag, for eg. if new version is going to be `v0.1.2` then release candidate branch should be `v0.1.2-rc.0`
+
+- Run tests to ensure stability. If issues/bugs are found, submit patches to the RC's release branch and create a new RC with the tag `vX.Y.Z-rc.W+1`. Apply those same patches to the `master` branch. Repeat until the release is suitably stable.


We should merge the fix to master and then cherry pick to the release branch (similar to kubernetes)

…-driver into release-management

aramase · 2021-06-25T19:42:14Z

/ok-to-test

tam7t · 2021-06-25T20:27:42Z

/lgtm

aramase

/approve

k8s-ci-robot · 2021-06-25T20:35:40Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aramase, nilekhc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [aramase]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

nilekhc added 2 commits May 18, 2021 15:32

docs: adds release management guidelines

383dda2

chore: updates document

43717bc

Signed-off-by: Nilekh Chaudhari <1626598+nilekhc@users.noreply.github.com>

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 18, 2021

k8s-ci-robot requested review from aramase and ritazh May 18, 2021 22:42

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label May 18, 2021

k8s-ci-robot assigned tam7t May 18, 2021

k8s-ci-robot requested a review from tam7t May 19, 2021 17:44

k8s-ci-robot added kind/documentation Categorizes issue or PR as related to documentation. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. labels May 19, 2021

aramase added this to the v0.0.23 milestone May 20, 2021

tam7t reviewed May 24, 2021

View reviewed changes

aramase modified the milestones: v0.0.23, v0.1.0 May 28, 2021

aramase reviewed Jun 7, 2021

View reviewed changes

nilekhc added 4 commits June 8, 2021 14:19

Merge branch 'master' of https://github.com/nilekhc/secrets-store-csi…

aab3969

…-driver into release-management

docs: updates major release def and release window

48b9e9a

Merge branch 'master' of https://github.com/nilekhc/secrets-store-csi…

301a571

…-driver into release-management

docs: updates release process.

c160fe0

nilekhc requested review from aramase and tam7t June 10, 2021 20:39

k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 25, 2021

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 25, 2021

aramase reviewed Jun 25, 2021

View reviewed changes

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 25, 2021

k8s-ci-robot merged commit c6eb7bf into kubernetes-sigs:master Jun 25, 2021

nilekhc deleted the release-management branch June 25, 2021 20:54

nilekhc mentioned this pull request Jul 20, 2021

REQUEST: New membership for nilekhc kubernetes/org#2837

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release management #555

Release management #555

nilekhc commented May 18, 2021

k8s-ci-robot commented May 18, 2021

nilekhc commented May 18, 2021

k8s-ci-robot commented May 18, 2021

k8s-ci-robot commented May 18, 2021

nilekhc commented May 19, 2021

aramase commented May 19, 2021

tam7t May 24, 2021

aramase Jun 7, 2021 •

edited

Loading

tam7t Jun 9, 2021

tam7t May 24, 2021

nilekhc May 27, 2021

tam7t Jun 9, 2021

nilekhc Jun 10, 2021

tam7t Jun 25, 2021

aramase Jun 7, 2021 •

edited

Loading

aramase Jun 7, 2021

nilekhc Jun 10, 2021

aramase commented Jun 25, 2021

tam7t commented Jun 25, 2021

aramase left a comment

k8s-ci-robot commented Jun 25, 2021


		- A new release should be created on the _`second Wednesday`_ of each month. This schedule not only allows us to do bug fixes, but also provides an opportunity to address underline image vulnerabilities etc. if any.

		- Once the new version is decided(as per above guideline), release candidate branch should be created from `master` with name `vX.Y.Z-rc.W` followed by release with same tag, for eg. if new version is going to be `v0.1.2` then release candidate branch should be `v0.1.2-rc.0`


		- Once the new version is decided(as per above guideline), release candidate branch should be created from `master` with name `vX.Y.Z-rc.W` followed by release with same tag, for eg. if new version is going to be `v0.1.2` then release candidate branch should be `v0.1.2-rc.0`

		- Run tests to ensure stability. If issues/bugs are found, submit patches to the RC's release branch and create a new RC with the tag `vX.Y.Z-rc.W+1`. Apply those same patches to the `master` branch. Repeat until the release is suitably stable.

Release management #555

Release management #555

Conversation

nilekhc commented May 18, 2021

k8s-ci-robot commented May 18, 2021

nilekhc commented May 18, 2021

k8s-ci-robot commented May 18, 2021

k8s-ci-robot commented May 18, 2021

nilekhc commented May 19, 2021

aramase commented May 19, 2021

Choose a reason for hiding this comment

aramase Jun 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aramase Jun 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aramase commented Jun 25, 2021

tam7t commented Jun 25, 2021

aramase left a comment

Choose a reason for hiding this comment

k8s-ci-robot commented Jun 25, 2021

aramase Jun 7, 2021 •

edited

Loading

aramase Jun 7, 2021 •

edited

Loading