Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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
Move cert-manager to the github.com/cert-manager organization #624
Move cert-manager to the github.com/cert-manager organization #624
Changes from all commits
55f8a40
8f617d8
5751905
b649397
85c2904
053b13c
923df41
eb586df
d25c803
60c1e35
85369f4
7b07ecb
2a0542b
958bdd9
49e8320
0c6b483
3b13569
6955381
650d8a9
6658849
c01d55f
5a347db
b295af4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we not been freezing merges during a codefreeze near release? If so, +1 to this going. But this was here so that we could block merges unless they were explicitly in the milestone we are soon to be releasing.
(i.e. near 1.7 release, PRs must have the
v1.7
milestone on them to be merged to master). The idea being to make it possible to lgtm/approve stuff despite it being targeted to land in thev1.8
release.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not the documented process anyway. https://cert-manager.io/docs/contributing/release-process/#process-for-releasing-a-version
We fast-forward the release-x.y.z branch for alpha releases and for the first beta release
and then do cherry-picks after that.
What's the use-case for / advantage of the milestone check?
I guess if there's a feature which is definitely not to be in the next release and that is being merged in parts and partly merged even before the first beta, then that should be merged not into master, but into a feature-branch which can then be merged once the feature is complete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea stems from the "code freeze" concept in Kubernetes where after a certain point in the release (I believe when the first beta is cut), "milestone maintainers" are the only ones that can use the
/milestone
command to add a milestone to PRs.The master branch begins requiring that PRs into master must be explicitly approved for the upcoming release - so anything that isn't approved won't actually merge until the code freeze is lifted (which I believe in k8s is when the first RC of the next release is cut).
This means:
lgtm
andapproved
only (like we do today)lgtm
,approved
and target milestoneN
. We then continue to fast forward the release branch to the tip of HEAD. The idea is to encourage PRs that focus on stability of the upcoming release (or in some instances, feature PRs that have been excepted as they are almost ready and just need a few extra fixes/deemed to be critical and there's been a discussion to allow it).After the stable 'N' is cut, not much changes from the RC phase except things targeting the release branch are now going to land in
vMAJOR.N.1
(i.e. the first patch release of release N after the initial stable).We don't do release candidates (RCs) so that step hasn't really ever been done, but we've enforced this for a handful of releases in the past (though not recently!)