Status

• 2024-09-05 - Migrated to Shipyard Notion
• 2023-10-05 - Added info about doing release on Wednesdays and having a code freeze.
• 2022-10-12 - Added steps about what happens at the end of the release process.
• 2022-06-08 - Original drafting

Summary

As of 2022Q3, the core maintainers are switching to a scheduled release every 5 weeks. 4 weeks after the last release we cut an RC, and the final release the week after that assuming no blocking bugs identified.

Context and Why

Kubo in 2021 and 2022H1 historically released at an ad-hoc schedule when there was a team conviction on enough pent up need and/or convenience for an engineer to do the release. The problem with this approach is that the changeset could get so long that when we’d go to finally do the release, everything would usually take even longer than planned (e.g., writing release notes, testing). The team experienced a tipping point with the 0.13 release in 202206 (‣), with its multiple breaking changes, libp2p upgrades, etc.

Moving to a predictable release schedule makes life more predictable for the maintainers. Specifically we get predictability in:

1. Dev effort to make it happen because less likely to have large batch of changes.
2. Scheduling/planning for PL EngRes infra for deploying updates and dogfooding.

How?

1. All specific work happens per the release checklist template that is copy/pasted into each new release issue in the Kubo repo. Progress and status updates on the release are communicated in the release issue.
2. The release issue has an owner who is responsible for driving and executing the release.
   1. The release owner is stated in the release issue.
   2. This responsibility is rotated amongst team members each release so that all are capable of doing a release if necessary and to share the load.
   3. Dangerous commands like git tagging should be “2-person reviewed” by someone else, to minimize the risk of irreversible mistakes
3. The release also has a designated reviewer so that the release owner can get get quick reviews.
   1. By default the release reviewer is the previous release owner.
   2. This is also stated in the release issue.
   3. Significant time is spent doing PRs and 2-person-reviews for releases, and delays in reviews cause significant release delays, so the reviewer should be ready to respond to PRs and 2-person-reviews promptly
   4. Reviewer should plan to spend a few hours reviewing PRs for the release owner.

Schedule Overview