Difference between revisions of "StarlingX/Releases/Release Notes"
(→Intro) |
|||
Line 1: | Line 1: | ||
== Intro == | == Intro == | ||
− | + | [[StarlingX/Docs_and_Infra]] is working in collaboration with Tech Writers team to document StarlingX APIs, this page reflects the research on what it means for StarlingX. | |
+ | <br> | ||
+ | * Storyboard [https://storyboard.openstack.org/#!/story/2003101 Process Release Management Implementation ] | ||
+ | <br> | ||
+ | Important! | ||
* It is worth to spent some time reading the 15 minute [ https://docs.openstack.org/reno/latest/ Reno Documentation]. | * It is worth to spent some time reading the 15 minute [ https://docs.openstack.org/reno/latest/ Reno Documentation]. | ||
* [http://lists.starlingx.io/pipermail/starlingx-discuss/2018-August/000690.html Doc Release Notes Management Mailing List]. | * [http://lists.starlingx.io/pipermail/starlingx-discuss/2018-August/000690.html Doc Release Notes Management Mailing List]. |
Revision as of 14:35, 15 August 2018
Contents
Intro
StarlingX/Docs_and_Infra is working in collaboration with Tech Writers team to document StarlingX APIs, this page reflects the research on what it means for StarlingX.
- Storyboard Process Release Management Implementation
Important!
- 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.
StarlingX
- openstack/stx-clients
- openstack/stx-config
- openstack/stx-docs
- openstack/stx-fault
- openstack/stx-gui
- openstack/stx-ha
- openstack/stx-integ
- openstack/stx-manifest
- openstack/stx-metal
- openstack/stx-nfv
- openstack/stx-root
- openstack/stx-tis-repo
- openstack/stx-tools
- Storyboard Task 24554 Doc: Release Notes Management
- [Doc Release Notes Management]
- openstack/stx-update
- openstack/stx-upstream
Baseline
Release Notes Management baseline is ready for review, once this is approved it will be ported to the rest of our projects.w:
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:
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.