[Starlingx-discuss] [Doc] Release Notes Management
Release Notes are ready to get incorporated into our StarlingX projects. It is worth to spent some time reading the 15 minute Reno documentation [0]. [ Baseline ] Release Notes Management baseline is ready for review [1] [Doc] Release Notes Management 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 [2] Includeing both efforts: [Doc] [Demo] Release Notes m/2018.08 [ Grouping ] There is a convention to follow how Release Notes are grouped: - features - issues - upgrade - deprecations - critical - security - fixes - other See [3] for an example. [ Call to Action ] In my limited understanding a typical flow would be as follows: Developer [4] 1. Start common development workflow to create your change: "Hello My Change" 2. 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 3. Submit your change for review. Release Team 1. Start development work to prepare the release, this might include git tag. 2. Create to generate the Reno Report tox -e releasenotes 3. Submit your change for review. In OpenStack it seems OpenStack Release Bot takes care of the Release Process. See Nova Release Notes [5] for how it looks like. [0] https://docs.openstack.org/reno/latest/ [1] https://review.openstack.org/#/c/590798/5 [2] https://review.openstack.org/#/c/591157/2 [3] https://review.openstack.org/#/c/591157/2/releasenotes/notes/milestone-branc... [4] https://review.openstack.org/#/c/282520/ [5] https://docs.openstack.org/releasenotes/nova/rocky.html
participants (1)
-
Arce Moreno, Abraham