mirror of https://gitee.com/openkylin/pytest.git
d25cae754e | ||
---|---|---|
.. | ||
README.rst | ||
_template.rst |
README.rst
This directory contains "newsfragments" which are short files that contain a small **ReST**-formatted text that will be added to the next ``CHANGELOG``. The ``CHANGELOG`` will be read by **users**, so this description should be aimed to pytest users instead of describing internal changes which are only relevant to the developers. Make sure to use full sentences in the **past or present tense** and use punctuation, examples:: Improved verbose diff output with sequences. Terminal summary statistics now use multiple colors. Each file should be named like ``<ISSUE>.<TYPE>.rst``, where ``<ISSUE>`` is an issue number, and ``<TYPE>`` is one of: * ``feature``: new user facing features, like new command-line options and new behavior. * ``improvement``: improvement of existing functionality, usually without requiring user intervention (for example, new fields being written in ``--junitxml``, improved colors in terminal, etc). * ``bugfix``: fixes a bug. * ``doc``: documentation improvement, like rewording an entire session or adding missing docs. * ``deprecation``: feature deprecation. * ``breaking``: a change which may break existing suites, such as feature removal or behavior change. * ``vendor``: changes in packages vendored in pytest. * ``trivial``: fixing a small typo or internal change that might be noteworthy. So for example: ``123.feature.rst``, ``456.bugfix.rst``. If your PR fixes an issue, use that number here. If there is no issue, then after you submit the PR and get the PR number you can add a changelog using that instead. If you are not sure what issue type to use, don't hesitate to ask in your PR. ``towncrier`` preserves multiple paragraphs and formatting (code blocks, lists, and so on), but for entries other than ``features`` it is usually better to stick to a single paragraph to keep it concise. You can also run ``tox -e docs`` to build the documentation with the draft changelog (``doc/en/_build/html/changelog.html``) if you want to get a preview of how your change will look in the final release notes.