test_ok2/changelog
Ronny Pfannschmidt 0fdacb6db5 deprecate hook configuration via marks/attributes
fixes #4562
2022-09-20 16:22:26 +02:00
..
4562.deprecation.rst deprecate hook configuration via marks/attributes 2022-09-20 16:22:26 +02:00
7337.improvement.rst Warn when test functions return other than None (#9956) 2022-05-25 09:48:02 -03:00
8508.improvement.rst Enhance errors for exception/warnings matching (#8508) 2022-03-20 23:32:39 -03:00
8646.improvement.rst Update 8646.improvement.rst 2022-05-10 23:27:33 -07:00
9159.bugfix.rst fallback to native traceback when handling ExceptionGroup (take 2) [SQUASH] (#10209) 2022-08-17 09:16:32 -07:00
9248.doc.rst changelog: add missing entry for PR #9248 2022-08-15 19:07:36 +03:00
9291.doc.rst Update documentation on how pytest.warns affects DeprecationWarning #9291 (#10141) 2022-08-17 11:44:58 -03:00
9741.improvement.rst Use tomllib on Python 3.11 (#9741) 2022-04-17 21:11:17 +03:00
9742.improvement.rst Remove newlines from left/right operands with '-vv' (#9743) 2022-03-19 11:55:39 +00:00
9823.improvement.rst Add changelog 2022-03-29 12:37:23 +02:00
9873.improvement.rst Add CHANGELOG for #9873 (#9953) 2022-05-14 12:50:40 +02:00
9877.bugfix.rst Update changelog/9877.bugfix.rst 2022-07-07 09:39:57 -03:00
9883.improvement.rst Document the --code-highlight default (#9883) 2022-05-31 16:32:51 -03:00
9897.feature.rst Add shell-style wildcard support to 'testpaths' (#9897) 2022-05-24 10:20:51 +02:00
9906.trivial.rst Re-export importlib.metadata from _pytest.compat (#9906) 2022-05-01 10:05:41 +03:00
9910.trivial.rst Fix default encoding in cacheprovider 2022-05-03 20:56:46 +04:30
9920.improvement.rst Do not truncate crash messages in short test summary on CI (#9933) 2022-05-13 08:15:52 -03:00
9984.trivial.rst Improve error message in getfixturevalue 2022-05-23 17:54:22 +00:00
9987.improvement.rst Add support for .pytest.ini as an alternative to pytest.ini 2022-06-14 08:24:35 -03:00
10012.deprecation.rst Update :class:`pytest.PytestUnhandledCoroutineWarning` to a deprecation; it will raise an error in pytest 8. [SQUASH] (#10012) 2022-08-08 10:14:49 +01:00
10150.bugfix.rst Added file-like methods to DontReadFromInput (#10173) 2022-07-31 13:44:02 +00:00
10218.improvement.rst mark: allow any Sequence[str] for parametrize(argnames), not just list/tuple 2022-08-15 19:38:09 +03:00
README.rst docs: use doc/en/_build/html for html output (#6842) 2020-02-29 00:47:30 +01:00
_template.rst Update CHANGELOG template to put issue links at the start of entries 2018-07-07 11:02:33 -03:00

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.