Release documentation
Configure release documentation
Release notes
Notes are for the reader, not the author. A list of commit subjects is not release notes — it is a changelog with the interesting parts missing.
| Audience | Wants |
|---|---|
| End users | What changed for them, what to do differently |
| Operators | Breaking changes, migrations, configuration changes |
| Support | Fixed defects, with their identifiers |
Generating notes from linked work items rather than raw commits produces something readable, because a work item was written to describe intent while a commit message was written to describe a change. That link is the same traceability chain from Unit 1 Topic 1, used for a different purpose — and it fails the same way, silently, when commits carry no work item reference.
API documentation
Generate from source — OpenAPI, XML doc comments, docstrings — so the documentation cannot describe a signature the code does not have. Hand-written API reference is wrong the first time someone renames a parameter.
Publish it as a pipeline artifact and deploy it with the release, so the documentation version matches the deployed version. Documentation for tomorrow's API is as unhelpful as documentation for last year's.
Primary sources