release: add release process doc - #16935
Conversation
maykathm
added
Documentation
Skip spread
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #16935 +/- ##
==========================================
+ Coverage 78.94% 79.04% +0.09%
==========================================
Files 1371 1375 +4
Lines 190088 190999 +911
Branches 2446 2465 +19
==========================================
+ Hits 150067 150966 +899
- Misses 30908 30926 +18
+ Partials 9113 9107 -6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Mon May 4 09:19:18 UTC 2026 Spread tests skipped |
|
|
||
| Release notes: <link to NEWS.md file from PR> | ||
|
|
||
| Please refer to snapd release notes documentation to understand how this is put together: https://docs.google.com/document/d/1do2TFwRIAzuOjLmteVuD0CRoJNO5vVcdUIwTHo4bYO4/edit?tab=t.0#heading=h.ablpjof536fg |
There was a problem hiding this comment.
hm we really put a link to a non-public document in a public SRU bug report?
There was a problem hiding this comment.
Good point. @ernestl is this something we can change?
There was a problem hiding this comment.
I think we need to make all the bits we need public
There was a problem hiding this comment.
Indeed. There shouldn't be anything about the way we generate release notes that needs to be kept internal, although I recognise the increase in scope here.
There was a problem hiding this comment.
I've added what I think are the important bits from that documentation to this release doc. I then changed the template to point back to this doc. Let me know if this makes sense.
ernestl
left a comment
ernestl
left a comment
There was a problem hiding this comment.
First pass, probably good idea to have a sync chat.
| - If you are generating changelogs for a version that supersedes the major version, remove `New upstream releases, LP#<lp-number>` from the previous version. The `+<ubuntu release>` and the release name from the previous version should match those of the current minor version. | ||
| 4. Commit NEWS.md and the changelog updates as `release: <version>` into your personal branch | ||
| 5. Open the PR against `release/<version>` | ||
| - The PR description should be formatted as follows (only include the cherry picked section if you have cherry-picked commits): |
There was a problem hiding this comment.
Should we perhaps create a PR template in github and refer to it?
There was a problem hiding this comment.
I looked into creating a PR template. It looks to me like managing multiple templates is not amazing and might confuse people. I've left it as is. Feel free to push back if you think we should go ahead with it.
| style w4 fill:#222,stroke:#333 | ||
|
|
||
| subgraph t0 [" "] | ||
| T0L["<b>Prepare release content - 6 weeks</b>"]:::label |
There was a problem hiding this comment.
Would prefer that the release process initiates at the point where we approve the content, rather than 6 weeks earlier.
i.e. "PR 1/2/N testing" doesn't in fact happen under the responsibility of the release engineer.
There was a problem hiding this comment.
Changed. @ernestl I changed it to being 1 day to cut the release and create the PR. Sound good?
bboozzoo
left a comment
bboozzoo
left a comment
There was a problem hiding this comment.
LGTM. I gather that the original document did not receive as much scrutiny. Please see the comments from @ndyer, but otherwise I think we should land and execute the next release following the document closely. I'm expecting this will be enough to identify remaining issues or inconsistencies.
…unchpad Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
ernestl
left a comment
ernestl
left a comment
There was a problem hiding this comment.
This is really great, thanks Katie. I left a few comments for your consideration.
4 participants
No description provided.