cluster-api
cluster-api copied to clipboard
kubernetes-sigs
📖 doc: add release cycle doc
Signed-off-by: Stefan Büringer [email protected]
What this PR does / why we need it: Hey folks, this is the follow-up from the discussion during the office hours today.
The dates are preliminary but I think it it's good to have some specific dates already that we can move +/- a day or two if necessary.
The timeline is inspired by the Kubernetes timeline here (https://github.com/kubernetes/sig-release/blob/master/releases/release-1.26/README.md). They have a lot more dates in their timeline, but I think we should start small and then the first release team can add more dates (e.g. for things like writing release notes). But I think we also don't have to over-formalize it for now and define dates for everything
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #7389
Hey folks, just a general PSA, we would aim to merge this document until end of next week (before KubeCon) if no blocking issues are coming up. Just to have the dates finalized. (as discussed in the office hours)
And pushed another version :)
One question I forgot to mention earlier: Looking through the k8s timeline doc, noticed they had a weekly meeting minutes (and a separate google doc) dedicated to the release team. Are we also planning to have one as well and if so, does it worth mentioning it in this document?
I think if we choose to have one as well it would be great to have it here. Essentially to have this as a landing page like they have it in upstream (~ https://github.com/kubernetes/sig-release/tree/master/releases/release-1.26). If this page gets to big we can also split it up in one per-release.
As we didn't discuss/decide yet how the release team organizes itself I would wait for that and then the page can be adjusted accordingly. I'll make a note in the umbrella issue that we have to figure out how the release team coordinates itself / the working model of the release team.
Thanks @sbueringer for putting this together :)) The document content looks good to me.
One thought should we go into more modular approach like done for the Kubernetes release repository link
Something I tried to sketch out, please have a look.
The thought behind this approach was to keep process smoother in later releases because like adding timelines for all cycles in one document like above will keep increasing the document too much I feel.
Open for everyone's suggestion :))
@VibhorChinda I think you're suggestion is fine. I just wanted to keep it in one doc for the start and we can split it up later when we add more.
As of today we just don't have the same complexity as Kubernetes has and I would want to wait and see if we actually get to that or even need it. (just looking at all the docs they have...)
@VibhorChinda I think you're suggestion is fine. I just wanted to keep it in one doc for the start and we can split it up later when we add more.
As of today we just don't have the same complexity as Kubernetes has and I would want to wait and see if we actually get to that or even need it. (just looking at all the docs they have...)
Understood 👍🏻 :))
(just updated the v1.2.x releases now that we did an additional v1.2.4 bug-fix release)
@CecileRobertMichon @fabriziopandini I would merge on Friday? (not EOD :))
/approve /hold until Friday Oct 21st to merge, pending last minute comments
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: vincepri
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [vincepri]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
