Add new-note tox environment
Only reno command was possible to add a release notes. modify tox config to allow newnote command too. Change-Id: I12ac14f664f59dbab11ded5f420de4ea290f21f6
This commit is contained in:
parent
5c150c8cf4
commit
9f0aaf7dd4
174
doc/source/contributor/adding_release_notes.rst
Normal file
174
doc/source/contributor/adding_release_notes.rst
Normal file
@ -0,0 +1,174 @@
|
|||||||
|
.. _adding_release_notes:
|
||||||
|
|
||||||
|
Release Notes
|
||||||
|
=============
|
||||||
|
|
||||||
|
What are release notes?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Release notes are important for change management within manila. Since manila
|
||||||
|
follows a release cycle with milestones, release notes provide a way for the
|
||||||
|
community and users to quickly grasp what changes occurred within a development
|
||||||
|
milestone. To the OpenStack release management and documentation teams,
|
||||||
|
release notes are a way to compile changes per milestone. These notes are
|
||||||
|
published on the `OpenStack Releases website <http://releases.openstack.org>`_.
|
||||||
|
Automated tooling is built around ``releasenotes`` and they get appropriately
|
||||||
|
handled per release milestone, including any back-ports to stable releases.
|
||||||
|
|
||||||
|
What needs a release note?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* Changes that impact an upgrade, most importantly, those that require a
|
||||||
|
deployer to take some action while upgrading
|
||||||
|
|
||||||
|
* A new feature is implemented
|
||||||
|
* An existing feature is deprecated
|
||||||
|
* An existing feature is removed
|
||||||
|
* Behavior of an existing feature has changed in a discernible way to an end
|
||||||
|
user or administrator
|
||||||
|
* A security bug is fixed
|
||||||
|
* New configuration option is added
|
||||||
|
|
||||||
|
What does not need a release note?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* A code change that doesn't change the general behavior of any
|
||||||
|
feature such as code refactor or logging changes.
|
||||||
|
* Functional or unit test coverage enhancement
|
||||||
|
* Changes to the content of an error message displayed on the UI
|
||||||
|
* Any change submitted with a justified TrivialFix flag added in the commit
|
||||||
|
message
|
||||||
|
* Adding or changing documentation within in-tree documentation guides
|
||||||
|
|
||||||
|
How do I add a release note?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
We use `Reno <https://docs.openstack.org/reno/latest/>`_ to create and manage
|
||||||
|
release notes. The new subcommand combines a random suffix with a "slug" value
|
||||||
|
to make the new file with a unique name that is easy to identify again later.
|
||||||
|
To create a release note for your change, use:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ reno new slug-goes-here
|
||||||
|
|
||||||
|
If reno is not installed globally on your system, you can use a tox
|
||||||
|
environment in manila:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ tox -e newnote slug-goes-here
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
When you are adding a bug-fix reno, name your file using the template:
|
||||||
|
"bug-<launchpad-bug-id>-slug-goes-here".
|
||||||
|
|
||||||
|
Then add the notes in ``yaml`` format in the file created. Pay attention to the
|
||||||
|
type of section. The following are general sections to use:
|
||||||
|
|
||||||
|
prelude
|
||||||
|
|
||||||
|
General comments about the change. The prelude from all notes in a
|
||||||
|
release are combined, in note order, to produce a single prelude
|
||||||
|
introducing the release.
|
||||||
|
|
||||||
|
features
|
||||||
|
|
||||||
|
New features introduced
|
||||||
|
|
||||||
|
issues
|
||||||
|
|
||||||
|
A list of known issues with respect to the change being introduced. For
|
||||||
|
example, if the new feature in the change is experimental or known to not
|
||||||
|
work in some cases, it should be mentioned here.
|
||||||
|
|
||||||
|
upgrade
|
||||||
|
|
||||||
|
A list of upgrade notes in the release. Any removals that affect upgrades are
|
||||||
|
to be noted here.
|
||||||
|
|
||||||
|
deprecations
|
||||||
|
|
||||||
|
Any features, APIs, configuration options that the change has deprecated.
|
||||||
|
Deprecations are not removals. Deprecations suggest that there will be
|
||||||
|
support for a certain timeline. Deprecation should allow time for users
|
||||||
|
to make necessary changes for the removal to happen in a future release.
|
||||||
|
It is important to note the timeline of deprecation in this section.
|
||||||
|
|
||||||
|
critical
|
||||||
|
|
||||||
|
A list of *fixed* critical bugs (descriptions only).
|
||||||
|
|
||||||
|
security
|
||||||
|
|
||||||
|
A list of *fixed* security issues (descriptions only).
|
||||||
|
|
||||||
|
fixes
|
||||||
|
|
||||||
|
A list of other *fixed* bugs (descriptions only).
|
||||||
|
|
||||||
|
other
|
||||||
|
|
||||||
|
Other notes that are important but do not fall into any of the given
|
||||||
|
categories.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
---
|
||||||
|
prelude: >
|
||||||
|
Replace this text with content to appear at the
|
||||||
|
top of the section for this change.
|
||||||
|
features:
|
||||||
|
- List new features here, or remove this section.
|
||||||
|
issues:
|
||||||
|
- List known issues here, or remove this section.
|
||||||
|
upgrade:
|
||||||
|
- List upgrade notes here, or remove this section.
|
||||||
|
deprecations:
|
||||||
|
- List deprecation notes here, or remove this section
|
||||||
|
critical:
|
||||||
|
- Add critical notes here, or remove this section.
|
||||||
|
security:
|
||||||
|
- Add security notes here, or remove this section.
|
||||||
|
fixes:
|
||||||
|
- Add normal bug fixes here, or remove this section.
|
||||||
|
other:
|
||||||
|
- Add other notes here, or remove this section.
|
||||||
|
|
||||||
|
|
||||||
|
Dos and Don'ts
|
||||||
|
~~~~~~~~~~~~~~
|
||||||
|
* Release notes need to be succinct. Short and unambiguous descriptions are
|
||||||
|
preferred
|
||||||
|
* Write in past tense, unless you are writing an imperative statement
|
||||||
|
* Do not have blank sections in the file
|
||||||
|
* Do not include code or links
|
||||||
|
* Avoid special rst formatting unless absolutely necessary
|
||||||
|
* Always prefer including a release note in the same patch
|
||||||
|
* Release notes are not a replacement for developer/user/admin documentation
|
||||||
|
* Release notes are not a way of conveying behavior of any features or usage of
|
||||||
|
any APIs
|
||||||
|
* Limit a release note to fewer than 2-3 lines per change per section
|
||||||
|
* OpenStack prefers atomic changes. So remember that your change may need the
|
||||||
|
fewest sections possible
|
||||||
|
* General writing guidelines can be found
|
||||||
|
`here <https://docs.openstack
|
||||||
|
.org/doc-contrib-guide/writing-style/general-writing-guidelines.html>`_
|
||||||
|
* Proofread your note. Pretend you are a user or a deployer who is reading
|
||||||
|
the note after a milestone or a release has been cut
|
||||||
|
|
||||||
|
Examples
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
The following need only be considered as directions for formatting. They
|
||||||
|
are **not** fixes or features in manila.
|
||||||
|
|
||||||
|
|
||||||
|
* *add-share-network-create-workflows-41cad17c1498a3.yaml*
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
---
|
||||||
|
features:
|
||||||
|
- switched share network creation into two-step workflows.
|
@ -8,3 +8,10 @@ Contributor Documentation
|
|||||||
contributing
|
contributing
|
||||||
development-environment
|
development-environment
|
||||||
features
|
features
|
||||||
|
|
||||||
|
Programming HowTos and Tutorials
|
||||||
|
--------------------------------
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 3
|
||||||
|
|
||||||
|
adding_release_notes
|
6
tox.ini
6
tox.ini
@ -41,6 +41,12 @@ setenv =
|
|||||||
HORIZON_INTEGRATION_TESTS_CONFIG_FILE=manila_ui/tests/integration/horizon.conf
|
HORIZON_INTEGRATION_TESTS_CONFIG_FILE=manila_ui/tests/integration/horizon.conf
|
||||||
commands = {envpython} {toxinidir}/manage.py test manila_ui --settings=manila_ui.tests.settings --tag integration
|
commands = {envpython} {toxinidir}/manage.py test manila_ui --settings=manila_ui.tests.settings --tag integration
|
||||||
|
|
||||||
|
[testenv:newnote]
|
||||||
|
deps =
|
||||||
|
-c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master}
|
||||||
|
-r{toxinidir}/doc/requirements.txt
|
||||||
|
commands = reno new {posargs}
|
||||||
|
|
||||||
[testenv:pep8]
|
[testenv:pep8]
|
||||||
commands = flake8
|
commands = flake8
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user