Jump to: navigation, search

StarlingX/Releases/Release Notes

< StarlingX‎ | Releases
Revision as of 02:45, 26 September 2018 by Abraham.arce.moreno (talk | contribs) (Tracking)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.


Important!

Tracking

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

  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.