Release notes management tool
Go to file
Doug Hellmann 9f866b35a1 only override config values from command line if they are actually set
If we set defaults for the query configuration options and then pass
the namespace created by parsing the command line options to the
config object it cannot tell the difference between values set on the
command line and defaults. That means we may override settings in the
configuration file with defaults from the command line parser.

This change sets all of the defaults for command line options to None
as a sentinel value and then updates the Config class to ignore
command line option values of None. It also adds tests to verify that
we get the expected override behavior with boolean and string options.

Change-Id: I1c9ce668b5e5c372d1c861bcae6e6de05a8ebc0c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2018-10-10 12:55:11 -04:00
doc/source update the oudated URL in doc 2018-09-23 17:44:29 +08:00
examples/notes expand examples in documentation 2017-06-06 17:07:08 -04:00
releasenotes/notes only override config values from command line if they are actually set 2018-10-10 12:55:11 -04:00
reno only override config values from command line if they are actually set 2018-10-10 12:55:11 -04:00
.coveragerc Change ignore-errors to ignore_errors 2015-09-21 14:55:10 +00:00
.gitignore Integrate a setuptools command 2018-04-11 09:26:36 +01:00
.gitreview Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
.mailmap Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
.testr.conf Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
.zuul.yaml add lower-constraints tox environment and job 2018-09-04 15:11:16 -04:00
CONTRIBUTING.rst update bug report URLs to use storyboard 2018-03-14 10:52:29 -04: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 update bug report URLs to use storyboard 2018-03-14 10:52:29 -04:00
bindep.txt update bindep list 2017-11-15 14:25:34 -05:00
lower-constraints.txt update sphinx to at least 1.6.1 2018-09-04 16:56:40 -04:00
requirements.txt add lower-constraints tox environment and job 2018-09-04 15:11:16 -04:00
setup.cfg build universal wheels 2018-10-02 16:42:38 -04:00
setup.py Initial Cookiecutter Commit. 2015-08-26 20:04:56 +00:00
test-requirements.txt switch from oslosphinx to openstackdocstheme 2017-06-28 14:46:09 -04:00
tox.ini build our docs with the lower-constraints 2018-09-04 16:56:40 -04:00

README.rst

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