Skip to content

[v1.36] Release Team Lead Cycle Progress #2934

New issue
New issue
Open
Open
[v1.36] Release Team Lead Cycle Progress#2934
Assignees
rytswd
Labels
area/release-engIssues or PRs related to the Release Engineering subprojectarea/release-teamIssues or PRs related to the release-team subprojectneeds-kindIndicates a PR lacks a `kind/foo` label and requires one.needs-prioritysig/releaseCategorizes an issue or PR as relevant to SIG Release.
@rytswd

Description

@rytswd
rytswd
opened on Jan 6, 2026

Additional information can be found in the release team lead handbook. If tasks are not needed to be done or additional tasks are required, make sure to update the issue template!

Note: Any item with 🟠 denotes that it may require issue template update.

Release Lead tasks

1. Before the start of the Release Cycle (Week 0)

  • Captured feedback from previous release cycle retro and planned to incorporate it into the release cycle
    • Had a catch-up with Drew, with focus on Release Signal
  • Release directory named release-1.36 added to k/sig-release/releases
  • Pruned the OWNERS file from the previous release cycle in k/sig-release/releases/release-1.XX
    • 🟠 I didn't take any actions on this, as OWNERS file now uses the OWNERS_ALIASES reference instead
    • 🟠 Updating OWNERS_ALIASES is a part of action items below, and should be merged here
  • Started planning the release schedule by opening a thread in #sig-release
  • Release Lead Shadows are confirmed
  • Team leads notified that all release team members read the release team onboarding document
  • Update slack channel descriptions for the #sig-release channel and all #release-xxx channels
    • #sig-release did not have any specific mention, and thus kept as is
  • Create links.md for quicklinks
  • Add v1.36 milestone
    • There is a discussion around when to create for future releases
    • @dipesh-rawat helped with the milestone creation of v1.36 for this cycle
    • 🟠 We will need to track this as a post release action item, or handbook item

Release Lead Onboarding:

  • Release Team Lead, Lead Shadows, and Subteam Leads have agreed to abide by the guidelines set forth in the
    Security Release Process, specifically the embargo on CVE communications.
    This must be done as an issue comment by each of the above named individuals.
  • Release Team Lead, Lead Shadows, and Subteam Leads have been through Linux Foundation Training - LFC101 or LFC102 and have shared their certificate of completion in the issue comments.
  • Updated GitHub teams (kubernetes/org)
  • Updated kubernetes/sig-release OWNERS_ALIASES
    • release-team-lead - release lead
    • release-team-lead-shadows - release lead shadows
    • communications-subteam-approvers - communications lead
    • docs-subteam-approvers - docs lead
    • enhancements-subteam-approvers - enhancements lead
    • release-signal-subteam-approvers - release signal lead
    • Update OWNERS_ALIASES with v1.36 Release team #2937
  • Updated Google Groups/GCP IAM membership (kubernetes/k8s.io)
  • Release Team calendar access granted (reach out to sig-release chairs)
    • Kat helped me with the access
  • Zoom credentials (host key) granted (reach out to sig-release chairs)
    • Reached out to the chairs via DM
  • Added incoming release team leads to release-team-leads Slack Group (kubernetes/community)
  • Ensured the Release Team subproject owners are the owners of the release-team-shadows Google Group at (kubernetes/k8s.io)
  • Ensured top-level OWNERS_ALIASES only includes Release Team personnel from four (4) releases, including the current one.
    • 🟠 This should be mentioned with the OWNERS_ALIASES update above.

Create Release Team Documents:

One week before the start of the release cycle:

2. First weeks of the release cycle up to Enhancements Freeze (1-3 Weeks)

First Week of the release cycle:

  • Checked in with team leads and verified that the release team is complete

  • Reminded release team members to subscribe to the kubernetes-release-team and kubernetes-sig-release google groups and to the kubernetes-release calendar.

  • Notified team leads to update the contact sheet with shadow information rel.k8s.io/v1XX/contacts

  • Release schedule finalized

  • Begin paying attention to CI signal, as it may begin degrading soon after the prior release is cut and any slips must be caught and rectified promptly.

  • Meet your Shadows and create a communication channel with them. Establish expectations and share out work - delegate!

  • Pair your Shadows to support two subteams for the duration of the release.

  • Request review of this document by the Release Team Lead shadow(s). The shadow(s) should also take all actions in this document around joining groups and requesting access permissions.

  • Update the SIG Release groups in the k/k8s.io/groups/sig-release/groups.yaml with the following:

    • Add Lead and Lead shadows to members of k8s-infra-release-viewers
    • Add Lead, Lead shadows, comms lead, comms shadows to members of release-comms
    • Add Lead and Lead shadows to members of release-managers
    • Add Lead and Lead shadows to managers of release-team
    • Add Role Leads and Role shadows to members of release-team
    • Add Branch Managers to members of release-team
    • Add Role shadows and Lead shadows to members of release-team-shadows
    • Add Lead to manager of release-team-shadows
    • Add all v1.36 Release Team shadows to the appropriate groups k8s.io#9030
    • 🟠 2026-01-30: Because the same file is updated by multiple teams, I decided to pull all the changes into a single PR rather than asking for each one to be approved and potentially require another rebase from late ones. This is probably the best approach especially since the release team cannot self approve all the changes.
    • 🟠 2026-01-30: Also came to our attention how BRMs were not a part of the release-team, which they should be. A checkbox is added above.

  • Assist the Enhancements Lead in collecting planned work from SIGs

  • Discussed and scheduled a weekly Release Team meetings on a day that is most acceptable to the team. Invite the kubernetes-sig-release group.

  • Update the release calendar with the initial release meeting times and dates set to UTC.

  • Poll Release Team membership and schedule a weekly alternate meeting to better enable more attendance outside of the Americas.

  • Major release cycle events have been added to the Kubernetes Release Calendar with one week in advance reminders set. (defer to the handbook for more information)

Release Cut Alpha 1:

  • Checked in with release-signal and branch managers if 1.XX.0-alpha.1 is ok to be released and master-blocking tests are all green
  • Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.1 is generated

A week before Enhancements Freeze:

  • Remind the community about Enhancements Freeze reminder sent out
    • Example email: 1.26
    • It may also be useful to send a short version to the #sig-release and #chairs-and-techleads Slack channels referencing to the k-dev email.
    • 🟠 2026-02-04: We sent a PRR reminder email. As this is now enforced and comes before the Enhancements Freeze, we should add this as a part of action items in the next cycle.

3. Enhancements freeze up to Release Halfway Point (~Week 5 - 7)

General Tasks:

  • Bring exceptions to the #sig-release Slack channel and to Release Team meetings, and make sure SIG representatives for the exception(s) know to attend and discuss if necessary.
  • Begin casual observation of issues, CI signal, test flakes, and critical PRs
  • Release Team Retro is scheduled shortly after the "Release Halfway Point" and a host is selected
  • Make sure everyone knows the Docs deadline (PRs ready for review) is coming the following week. (around week 6)

Release Cut Alpha 2:

  • Checked in with release-signal and branch managers if 1.XX.0-alpha.2 is ok to be released and master-blocking tests are all green
  • Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.2 is generated

Removals, Deprecations, and Major Changes Blog:

  • Check in with release-comms if they are in contact with the release-enhancements team to collect "deprecations and removals" targeting the release
  • Identified with release-comms & sig-docs if a "Removals, Deprecations, and Major Changes" blog is needed and if so, started drafting it up (ref 1.26 blog)
  • Check with release-comms if they need help gathering "deprecations, removals and major changes" for the release. If so, assign KEPs to release lead shadows to collect this information from SIGs or identify highlight-worthy items themselves.

4. Release Halfway Point up to Code Freeze (~Week 8 - 11)

Release Cut Alpha 3:

  • Checked in with release-signal and branch managers if 1.XX.0-alpha.3 is ok to be released and master-blocking tests are all green
  • Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.3 is generated

General Tasks:

  • Send out a "Release Update / State of the Release", example: 1.26
  • Notify SIGs and about upcoming Code Freeze Deadline by sending an email to the kubernetes-dev list
  • The first retrospective meeting is scheduled for the first week of Monday, Wednesday, and Friday burndown meetings, typically mid-week. Confirm the release team subproject owner can serve as facilitator. If the subproject owner is unavailable then defer the responsibility as appropriate.
  • Make sure everyone knows the Docs deadline (PRs ready for review) is coming the following week.
  • Started release team meetings on Monday, Wednesday, and Friday
  • Pinged role leads reminding them to start considering succession plans. If they are handing the role off to a successor, identifying them early gives more time for the committed volunteer to get targeted mentoring.
  • Checked in with lead shadows and their assigned subteams to ensure they are on track with their responsibilities.

Removals, Deprecations, and Major Changes Blog:

  • A Release Team representative (ideally from release-comms) should attend the sig-docs meeting to raise awareness about the "Deprecations and Removals blog" for reviews.
  • The Deprecations and Removals blog is scheduled for next week shortly after Code Freeze. A draft of the blog should be started as reviews and iterations will be needed before publication next week
  • Ensured that "Removals, Deprecations, and Major Changes"-authors are reviewing the blog before it's being publicized

Release Highlights & Release Blog:

  • Followed up with SIGs on the release highlights of the release
  • Checked in with release-comms about the status of release highlights collection

5. Around Docs Freeze (~Week 12)

🟠 2026-01-30: This section is moved around in #2866, I need to review this further.

Defer to the Docs Freeze section in the release-team-lead handbook.

Shortly before Docs Freeze

  • Monitor the docs tab of the enhancements GitHub project to get an idea of how many PRs are still outstanding leading up to Docs Freeze.
  • Make sure everyone knows Docs Freeze is coming the following week. (week 12)

Week of Docs Freeze

  • As needed, assist the Docs subteam lead with any last-minute escalations.

After Docs Freeze

  • Bring exceptions to the #sig-release Slack channel, start a thread for each, and ensure SIG representatives for the exception(s) discuss in the thread.

6. Around Code Freeze (~Week 13)

Defer to the code freeze section in the release-team-lead handbook.

Shortly before Code freeze

Code Freeze begins, and it’s now the home stretch of the release. SIGs will need to ensure all work moving forward is carefully curated with required merge labels.

  • Monitor the enhancements GitHub project to get an idea of how many PRs are still outstanding leading up to Code Freeze
  • Monitor Testgrid and Prow to understand the stability of the release and PRs getting ready to merge. If Prow and Test grid are not in a good state consult folks from SIG Testing on delaying code freeze by a day if needed.
    • If the release branch is not healthy, stable, and passing tests consistently, notify community through standard channels of need to rectify or code freeze will come early to force focus on stabilization.
  • Reminded the Branch Manager that branch CI jobs will be needed next week
  • Send out a reminder email to kubernetes-dev

With Code Freeze

  • As needed, assist the Release Signal Lead and Enhancements Lead removing PRs and enhancements from the milestone that aren't merged in time /milestone clear

After Code Freeze

  • Verified that the release-1.XX branch has been created by the Branch Manager
  • Verified that the Branch Manager created the CI board on Testgrid for the release cycle (1.XX-blocking & 1.XX-informing)
  • Published the "Removals, Deprecations, and Major Changes blog"

7. Up to Release Day (~Week 14)

  • Verified together with the release-docs team that all KEPs with required documentation are ready for review
  • Completed release theme (slogan, logo and explanation text) and add it to the release cycle documentation in k/sig-release/releases/release-1.XX
  • Decided with the Release team if burndown meetings are necessary or updates are done via Slack thread on Tuesdays and Thursdays
  • Discussed Release Lead succession with the release team subproject owner and sig-release leads
  • Remind team lead to find successors for the upcoming cycle and discuss candidates with the subproject owner
  • The task is now to ensure the release branch is ready to go. This means there are zero pending PRs, no failing 1.XX-blocking tests, no open issues in the milestone. This will continue until release day.
  • Final documentation PRs are reviewed and ready to be merged. Likely, this is not true and some are outstanding, so you need to help convince SIG doc writers to get these in with urgency.
  • Planned something for Release Day. Make the day as fun as you can for the team. Plan ahead for this and do something nice
  • Prepared Release Team gifts
  • The Communications Lead contacts CNCF to gauge media interest, schedule the CNCF Kubernetes release workshop, and publish the release blog post. Stay in the loop for that. If there is media interest in the release, an interview between the journalist will be organized by the CNCF.
  • Check in with the docs lead and verify tasks that should happen before the release day are completed (ref release-docs handbook)
  • The Release Team Retro part 2 and part 3 is scheduled shortly after the "Release Halfway Point" and a host / facilitator is available
  • Remind the release team to add items to the retro meeting agenda

8. Release Day (~Week 15)

  • Note that release day can and should be postponed if any of the conditions outlined in week 11 are not satisfied.

  • Every issue in the milestone is considered release blocking

  • If you have to push the release date back, try to avoid Friday since it makes release publicity extremely difficult. Also, people seem to have patience with delay as long as the reasons are clear and openly communicated. This is your duty. You must over-communicate and ensure the team is also talking to their stakeholders (CNCF, community, press, etc.)

  • The following final actions must occur in order, with successful completion of each being the entry criteria to the next.

    • Release day morning:
      • Go / No-Go: should generally be clear a day or three ahead of release, but the day's burndown provides a final opportunity for the team to affirm things are ready.
      • Docs Lead PRs final draft release notes to sig-release, with Release Team Lead approving merge.
      • Branch Manager does mock release build.
      • Branch Manager does mock publication. Validates with Release Team lead and broader team the mock announcement email content.
      • Branch Manager does nomock release build.
    • Starting when ready:
      • Communications Lead should have completed staging blog post, merging the blog with draft:true and creating a second PR that removes the draft with a /hold label.
      • Branch Manager Lead does nomock publication.
      • Branch Manager affirms build is complete.
      • Verify with the docs lead that the staging release website is in correct shape by verifying the blog posts, the release page, download page, etc.
      • Docs Lead publishes release docs to website (ref tasks todo)
      • Branch Manager does release-notify.
    • Approximately 5pm Pacific: all work is complete and the release team
      lead announces release to k-dev, SIG Leads, and discuss.k8s.io.

  • After the release, it’s time to lift code freeze. The bot will need to be updated.

    • Thaw k/k,
      master branch is then opened for new pull requests.

  • The Docs lead thaws k/website

  • Use all of the appropriate communications channels to announce the lifting of Code Freeze and thawing of
    k/website, this can part of the release announcement.

9. After the Release Day (~Week 16, 17)

  • Release Retrospective Part 2 completed
  • Release Retrospective Part 3 completed or cancelled
  • Contact the Release Managers Google Group to complete the Release Team Lead & Lead Shadows offboarding tasks from the previously-opened onboarding issue
  • Help fill any open positions for the next release milestone
  • Work with the incoming Release Team Lead to establish incoming Release Team.

Release Lead Offboarding tasks:

  • Remove from GitHub teams (kubernetes/org)
    • milestone-maintainers
    • release-team
    • release-team-leads
    • release-team-XX (where XX is the release role, e.g. release-team-enhancements, release-team-docs, etc)
  • Remove from Google Groups/GCP IAM membership (kubernetes/k8s.io)
    • k8s-infra-release-viewers@
    • release-comms@
    • release-managers@
    • release-team@
    • release-team-shadows@
    • k8s-infra-staging-tg-exporter@
    • release-team-enhancements@
  • Manually remove from the following Google Groups:
  • Remove from release-team-leads Slack Group (kubernetes/community)

Further comments

NONE

cc: @kubernetes/release-engineering @kubernetes/release-team

Metadata

Metadata

Assignees

Labels

area/release-engIssues or PRs related to the Release Engineering subprojectarea/release-teamIssues or PRs related to the release-team subprojectneeds-kindIndicates a PR lacks a `kind/foo` label and requires one.needs-prioritysig/releaseCategorizes an issue or PR as relevant to SIG Release.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions