openstack/horizon
Code Issues Proposed changes
master
horizon/doc/source/contributor/topics/release-notes.rst
Akihiro Motoki c897a8e444 doc: Reorganize contributor doc 
Ussuri community goal "Project specific contributor and PTL docs"
want us to use doc/source/contributor/contributing.rst as an entry
point, but the current contributor/contributing.rst in horizon
contains a lot of information.

Before updating the file to satisfy the community goal criteria,
this commit reorganize the contributor doc.
It splits the existing contents in contributing.rst into pieces.

Change-Id: I8aa9a310a99e0eed5a93ed040a02a2829ee09bf7
2020-08-20 08:34:11 +09:00

1.9 KiB
Raw Permalink Blame History

Release Notes

Release notes for a patch should be included in the patch with the associated changes whenever possible. This allow for simpler tracking. It also enables a single cherry pick to be done if the change is backported to a previous release. In some cases, such as a feature that is provided via multiple patches, release notes can be done in a follow-on review.

If the following applies to the patch, a release note is required:

  • The deployer needs to take an action when upgrading
  • A new feature is implemented
  • Function was removed (hopefully it was deprecated)
  • Current behavior is changed
  • A new config option is added that the deployer should consider changing from the default
  • A security bug is fixed

Note

  • A release note is suggested if a long-standing or important bug is fixed. Otherwise, a release note is not required.
  • It is not recommended that individual release notes use prelude section as it is for release highlights.

Warning

Avoid modifying an existing release note file even though it is related to your change. If you modify a release note file of a past release, the whole content will be shown in a latest release. The only allowed case is to update a release note in a same release.

If you need to update a release note of a past release, edit a corresponding release note file in a stable branch directly.

Horizon uses reno to generate release notes. Please read the docs for details. In summary, use

$ tox -e venv -- reno new <bug-,bp-,whatever>

Then edit the sample file that was created and push it with your change.

To see the results:

$ git commit  # Commit the change because reno scans git log.

$ tox -e releasenotes

Then look at the generated release notes files in releasenotes/build/html in your favorite browser.