Jump to: navigation, search

Difference between revisions of "StarlingX/Releases/Release Notes"

Line 20: Line 20:
* openstack/stx-docs
* openstack/stx-docs
* openstack/stx-fault
* openstack/stx-fault
** Storyboard Task [https://storyboard.openstack.org/#!/story/2003101 26696 Doc: Release Notes Management]
** Gerrit Review [ Doc Release Notes Management]
* openstack/stx-gui
* openstack/stx-gui
* openstack/stx-ha
* openstack/stx-ha

Revision as of 00:32, 25 September 2018


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.




Release Notes Management baseline is ready for review, once this is approved it will be ported to the rest of our projects.w:


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:


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:


  1. Start common development workflow to create your change:
    1. "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:
    1. 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
    1. 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 for how it looks like.