-
Notifications
You must be signed in to change notification settings - Fork 380
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
Document release notes process & introduce upgrade notes #2487
Conversation
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
One nit from PR description. I'm all for not having breaking changes however we may continue to deprecate flags, fields, and metrics as we go. Protobuf definitions and JSON I would consider user facing e.g. in a database somewhere so we probably need to keep those going for a very long time before deprecating. |
The idea is to write the upgrade notes alongside development, then copy them to release notes on a release. Instructions will be added soon. Signed-off-by: Anna Kapuscinska <[email protected]>
Signed-off-by: Anna Kapuscinska <[email protected]>
9d5de8b
to
4d87622
Compare
The guide covers release notes generated from the PRs based on release-note/* labels, as well as manually written upgrade notes. The pull request template links to this guide. Signed-off-by: Anna Kapuscinska <[email protected]>
4d87622
to
55a1895
Compare
It's intended to be used in the release process. Signed-off-by: Anna Kapuscinska <[email protected]>
* Mention isovalent/tetragon-github-tools which we started using for generating release notes * Add instructions for publishing upgrade notes Signed-off-by: Anna Kapuscinska <[email protected]>
55a1895
to
dc08936
Compare
I split script and release template updates into separate commits because the script should be backported into stable branches too. Since there are no concerns I'll merge after the CI passes. |
Documenting changes introduced in 1.1 release was not a trivial task, so here I'm attempting to improve the process around release & upgrade notes. There are two different aspects:
release-note
blurbs and labels in PRs (seedocs/content/en/docs/contribution-guide/release-notes.md
).contrib
dir and updated the release process.The first commit should be backported to the stable branches: v1.0 and v1.1.
Also I'm suggesting to stop using the
release-note/breaking-changes
label (it's not documented here) and highlight any potential breaking changes in the upgrade notes instead (with understanding that breaking changes should be avoided in the first place).Pinging @cilium/tetragon on this one. All of this makes sense only if Tetragon core developers follow these practices, so please review and comment if you disagree with something.