Fix doc issues in deprecation change (#9336)

Follow-up to #9309.

The issue in the changelog broke the docs build with:

doc/en/_changelog_towncrier_draft.rst:47: WARNING: Inline literal start-string
without end-string.

The second change isn't as critical, but caused the text to be rendered as
monospace including the tilde (i.e. `~pytest.PytestDeprecationwarning`).
This commit is contained in:
Florian Bruhin 2021-11-25 09:43:23 +01:00 committed by GitHub
parent df9e94fbca
commit 8436d695e5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 2 additions and 2 deletions

View File

@ -1,7 +1,7 @@
**PytestRemovedIn7Warning deprecation warnings are now errors by default.**
Following our plan to remove deprecated features with as little disruption as
possible, all warnings of type ``PytestRemovedIn7Warning `` now generate errors
possible, all warnings of type ``PytestRemovedIn7Warning`` now generate errors
instead of warning messages by default.
**The affected features will be effectively removed in pytest 7.1**, so please consult the

View File

@ -22,7 +22,7 @@ b) transitional: the old and new API don't conflict
We will only start the removal of deprecated functionality in major releases (e.g. if we deprecate something in 3.0 we will start to remove it in 4.0), and keep it around for at least two minor releases (e.g. if we deprecate something in 3.9 and 4.0 is the next release, we start to remove it in 5.0, not in 4.0).
A deprecated feature scheduled to be removed in major version X will use the warning class `PytestRemovedInXWarning` (a subclass of `~pytest.PytestDeprecationwarning`).
A deprecated feature scheduled to be removed in major version X will use the warning class `PytestRemovedInXWarning` (a subclass of :class:`~pytest.PytestDeprecationwarning`).
When the deprecation expires (e.g. 4.0 is released), we won't remove the deprecated functionality immediately, but will use the standard warning filters to turn `PytestRemovedInXWarning` (e.g. `PytestRemovedIn4Warning`) into **errors** by default. This approach makes it explicit that removal is imminent, and still gives you time to turn the deprecated feature into a warning instead of an error so it can be dealt with in your own time. In the next minor release (e.g. 4.1), the feature will be effectively removed.