StarlingX/Releases/Release Notes
Intro
- Release Notes are ready to get incorporated into our StarlingX projects.
- It is worth to spent some time reading the 15 minute [ https://docs.openstack.org/reno/latest/ Reno Documentation].
- Doc Release Notes Management Mailing List.
Baseline
Release Notes Management baseline is ready for review:
Once this is approved it will be ported to the rest of our projects.
Demo
To generate our Release Note and Report a small amount of effort is required from both our Developers and our Release team. Here you have a demo for Milestone branch m/2018.08 including both efforts: [Doc] [Demo] Release Notes m/2018.08 https://review.openstack.org/#/c/591157/2
Grouping
There is a convention to follow how Release Notes are grouped:
- features
- issues
- upgrade
- deprecations
- critical
- security
- fixes
- other
See this link as an example:
Call to Action
In my limited understanding a typical flow would be as follows:
Developer
- Start common development workflow to create your change:
- "Hello My Change"
- New! Create its release notes in reStructuredText, no major effort since title and content might be reused from git commit information:
- tox -e venv -- reno new hello-my-change
- Submit your change for review.
Release Team
- Start development work to prepare the release, this might include git tag.
- Create to generate the Reno Report
- tox -e releasenotes
- Submit your change for review.
In OpenStack it seems OpenStack Release Bot takes care of the Release Process.
See Nova Release Notes for how it looks like.