• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

doc/source/H13-May-2018-758530

examples/notes/H13-May-2018-3833

releasenotes/notes/H13-May-2018-866675

reno/H13-May-2018-6,2524,756

reno.egg-info/H03-May-2022-8369

.coveragercH A D13-May-201889 86

.mailmapH A D13-May-201889 43

.testr.confH A D13-May-2018319 87

AUTHORSH A D13-May-20181.4 KiB3938

CONTRIBUTING.rstH A D13-May-2018658 1511

ChangeLogH A D13-May-20189.8 KiB378301

HACKING.rstH A D13-May-2018154 53

LICENSEH A D13-May-20189.9 KiB177149

MANIFEST.inH A D13-May-201894 75

PKG-INFOH A D13-May-20183.9 KiB8268

README.rstH A D13-May-20182.6 KiB5947

RELEASENOTES.rstH A D13-May-201816.8 KiB546340

setup.cfgH A D13-May-20181.2 KiB5848

setup.pyH A D13-May-20181,023 308

tox.iniH A D13-May-2018820 4132

README.rst

1=========================================
2 reno: A New Way to Manage Release Notes
3=========================================
4
5Reno is a release notes manager designed with high throughput in mind,
6supporting fast distributed development teams without introducing
7additional development processes.  Our goal is to encourage detailed
8and accurate release notes for every release.
9
10Reno uses git to store its data, along side the code being
11described. This means release notes can be written when the code
12changes are fresh, so no details are forgotten. It also means that
13release notes can go through the same review process used for managing
14code and other documentation changes.
15
16Reno stores each release note in a separate file to enable a large
17number of developers to work on multiple patches simultaneously, all
18targeting the same branch, without worrying about merge
19conflicts. This cuts down on the need to rebase or otherwise manually
20resolve conflicts, and keeps a development team moving quickly.
21
22Reno also supports multiple branches, allowing release notes to be
23back-ported from master to maintenance branches together with the
24code for bug fixes.
25
26Reno organizes notes into logical groups based on whether they
27describe new features, bug fixes, known issues, or other topics of
28interest to the user. Contributors categorize individual notes as they
29are added, and reno combines them before publishing.
30
31Notes can be styled using reStructuredText directives, and reno's
32Sphinx integration makes it easy to incorporate release notes into
33automated documentation builds.
34
35Notes are automatically associated with the release version based on
36the git tags applied to the repository, so it is not necessary to
37track changes manually using a bug tracker or other tool, or to worry
38that an important change will be missed when the release notes are
39written by hand all at one time, just before a release.
40
41Modifications to notes are incorporated when the notes are shown in
42their original location in the history. This feature makes it possible
43to correct typos or otherwise fix a published release note after a
44release is made, but have the new note content associated with the
45original version number. Notes also can be deleted, eliminating them
46from future documentation builds.
47
48Project Meta-data
49=================
50
51.. .. image:: https://governance.openstack.org/tc/badges/reno.svg
52    :target: https://governance.openstack.org/tc/reference/tags/index.html
53
54* Free software: Apache license
55* Documentation: https://docs.openstack.org/reno/latest/
56* Source: https://git.openstack.org/cgit/openstack/reno
57* Bugs: https://storyboard.openstack.org/#!/project/933
58* IRC: #openstack-release on freenode
59