cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Docsite: clarify a changelog entry format (#73902)

Browse source 
Co-authored-by: Felix Fontein <felix@fontein.de>
Co-authored-by: Felix Fontein <felix@fontein.de>
Co-authored-by: Felix Fontein <felix@fontein.de>
Co-authored-by: Sandra McCann <samccann@redhat.com>
This commit is contained in:
Andrew Klychkov 2021-03-24 16:21:34 +01:00 committed by GitHub
parent c4e211a429
commit 0543916a86
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
docs/docsite/rst/community/development_process.rst
View file

@ -184,7 +184,25 @@ A single changelog fragment may contain multiple sections but most will only con
Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself.
Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and the following sentence with a lowercase letter.
Most changelog entries are ``bugfixes`` or ``minor_changes``.
Changelog fragment entry format
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When writing a changelog entry, use the following format:
.. code-block:: yaml
- scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself).
The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``).
For changes that are not really scoped (for example, which affect a whole collection), use the following format:
.. code-block:: yaml
- Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself).
Here are some examples: