Skip to content

Support policy for new minor versions on older major versions #423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
k8s-ci-robot merged 1 commit into from
Apr 30, 2021
Merged

Support policy for new minor versions on older major versions #423

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions book/src/project-policies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,14 @@ A litmus test for not breaking compatibility is to replace the image of a
component in an existing deployment without changing that deployment in any
other way.

To minimize the number of branches we need to support, we do not have a general
policy for releasing new minor versions on older majors. We will make exceptions
for work related to meeting production readiness requirements. Only the previous
major version will be eligible for these exceptions, so long as the time between
the previous major version and the current major version is under six months.
For example, if "X.0.0" and "X+1.0.0" were released under six months apart,
"X.0.0" would be eligible for new minor releases.

Copy link
Contributor

@xing-yang xing-yang Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a clause that this older major can only be one version lower than the current major and also the time between the two major releases is less than 3-4 months, etc.

Copy link
Contributor Author

@chrishenzie chrishenzie Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Does the wording above make sense?

Copy link
Collaborator

@msau42 msau42 Apr 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure how to read this. Are we trying to say that if "X.0.0" and "X+1.0.0" were released about a quarter apart, then we will consider some exception?

But if it was "X.2.0" and "X+1.0.0", then we won't consider any exception?

Copy link
Contributor

@xing-yang xing-yang Apr 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like that. We only look at the initial release times of the major releases for minor release exceptions. Otherwise we could end up with too many releases. For example, if X.0.0 was released a year before X+1.0.0, we should move on and not to keep releasing minor releases on X.

Copy link
Contributor Author

@chrishenzie chrishenzie Apr 13, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the wording in this PR capture this in an understandable way? Or what if we worded it like so?

Only prior major versions released within four months of the current major version will be eligible for this exception.

This wording does broaden it to more than one major release, but maybe that's more intuitive than the current wording.

Copy link
Collaborator

@msau42 msau42 Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the wording as is captures it, but I wanted to confirm the intended scenario. Maybe give an example with numbers to make it more clear.

Copy link
Contributor Author

@chrishenzie chrishenzie Apr 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Contributor Author

@chrishenzie chrishenzie Apr 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking if this captures everything. Do we also want to add a section for RBAC not requiring new majors?

Copy link
Collaborator

@msau42 msau42 Apr 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think RBACs still require some more discussion, so let's consider that separately.

## Support

The Kubernetes CSI project follows the broader Kubernetes project on support.
Expand Down