Release notes management tool
Go to file
Dmitriy Rabotyagov 47651ec906 Respect EOM tag for branches in unmaintained status
With the new unmaintained process [1], branches are being tagged with
EOM before being removed.

This behaviour breaks reno, making it struggle to find respective origin
and leads to releasenotes job failure.

In order to overcome the issue we add eom tag to the list of expected ones
when we can not find the refferenced branch.

With that, EOL tag will have prescedence over EOM one.

[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html

Change-Id: Ic641af5aa65add9751b49fb47691a98f80a7c5a8
2024-02-29 11:29:56 +00:00
doc/source remove unicode from code 2022-08-25 09:46:52 +08:00
examples/notes Add support for subsections 2023-03-07 13:56:39 -06:00
releasenotes/notes Merge "Remove noisy log statement for deleted release notes" 2023-10-27 15:14:17 +00:00
reno Respect EOM tag for branches in unmaintained status 2024-02-29 11:29:56 +00:00
.coveragerc Change ignore-errors to ignore_errors 2015-09-21 14:55:10 +00:00
.gitignore Switch to use stestr for unit test 2018-10-22 10:01:52 -05:00
.gitreview OpenDev Migration Patch 2019-04-19 19:34:53 +00:00
.mailmap Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
.stestr.conf Switch to use stestr for unit test 2018-10-22 10:01:52 -05:00
.zuul.yaml Update supported python versions 2023-12-20 01:13:35 +09:00
bindep.txt Remove python-dev from bindep 2022-11-07 11:05:12 +01:00
CONTRIBUTING.rst [community goal] Update contributor documentation 2021-05-18 14:16:44 +00:00
HACKING.rst Update url in HACKING.rst 2018-02-26 01:46:34 +08:00
LICENSE Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
MANIFEST.in Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
README.rst Moving to OFTC 2021-06-16 12:05:30 +02:00
requirements.txt raise the minimum version of pyyaml 2020-08-29 17:41:39 -04:00
setup.cfg Update supported python versions 2023-12-20 01:13:35 +09:00
setup.py [ussuri][goal] Drop python 2.7 support and testing 2020-02-04 14:32:27 +01:00
test-requirements.txt Switch to newer openstackdocstheme version 2020-05-25 08:59:35 +02:00
tox.ini Use py3 as the default runtime for tox 2021-04-20 14:48:08 +08:00

reno: A New Way to Manage Release Notes

Reno is a release notes manager designed with high throughput in mind, supporting fast distributed development teams without introducing additional development processes. Our goal is to encourage detailed and accurate release notes for every release.

Reno uses git to store its data, along side the code being described. This means release notes can be written when the code changes are fresh, so no details are forgotten. It also means that release notes can go through the same review process used for managing code and other documentation changes.

Reno stores each release note in a separate file to enable a large number of developers to work on multiple patches simultaneously, all targeting the same branch, without worrying about merge conflicts. This cuts down on the need to rebase or otherwise manually resolve conflicts, and keeps a development team moving quickly.

Reno also supports multiple branches, allowing release notes to be back-ported from master to maintenance branches together with the code for bug fixes.

Reno organizes notes into logical groups based on whether they describe new features, bug fixes, known issues, or other topics of interest to the user. Contributors categorize individual notes as they are added, and reno combines them before publishing.

Notes can be styled using reStructuredText directives, and reno's Sphinx integration makes it easy to incorporate release notes into automated documentation builds.

Notes are automatically associated with the release version based on the git tags applied to the repository, so it is not necessary to track changes manually using a bug tracker or other tool, or to worry that an important change will be missed when the release notes are written by hand all at one time, just before a release.

Modifications to notes are incorporated when the notes are shown in their original location in the history. This feature makes it possible to correct typos or otherwise fix a published release note after a release is made, but have the new note content associated with the original version number. Notes also can be deleted, eliminating them from future documentation builds.

Project Meta-data