jiuyuan
/
test_ok1
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #6549 from blueyed/fix-release-minor 

doc: minor fixes for the release process
This commit is contained in:
Daniel Hahler 2020-01-24 13:36:48 +01:00 committed by GitHub
parent 38538c6c6d cdd6f86e43
commit 79d00ab35a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
HOWTORELEASE.rst
View File

@ -1,14 +1,14 @@
Release Procedure Release Procedure
----------------- -----------------
Our current policy for releasing is to aim for a bugfix every few weeks and a minor release every 2-3 months. The idea Our current policy for releasing is to aim for a bug-fix release every few weeks and a minor release every 2-3 months. The idea
is to get fixes and new features out instead of trying to cram a ton of features into a release and by consequence is to get fixes and new features out instead of trying to cram a ton of features into a release and by consequence
taking a lot of time to make a new one. taking a lot of time to make a new one.
.. important:: .. important::
pytest releases must be prepared on **Linux** because the docs and examples expect pytest releases must be prepared on **Linux** because the docs and examples expect
to be executed in that platform. to be executed on that platform.
#. Create a branch ``release-X.Y.Z`` with the version for the release. #. Create a branch ``release-X.Y.Z`` with the version for the release.

2
changelog/README.rst
View File

@ -15,7 +15,7 @@ Each file should be named like ``<ISSUE>.<TYPE>.rst``, where
* ``feature``: new user facing features, like new command-line options and new behavior. * ``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). * ``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 reported bug. * ``bugfix``: fixes a bug.
* ``doc``: documentation improvement, like rewording an entire session or adding missing docs. * ``doc``: documentation improvement, like rewording an entire session or adding missing docs.
* ``deprecation``: feature deprecation. * ``deprecation``: feature deprecation.
* ``removal``: feature removal. * ``removal``: feature removal.

2
doc/en/changelog.rst
View File

@ -2357,7 +2357,7 @@ Deprecations and Removals
- `#4036 <https://github.com/pytest-dev/pytest/issues/4036>`_: The ``item`` parameter of ``pytest_warning_captured`` hook is now documented as deprecated. We realized only after - `#4036 <https://github.com/pytest-dev/pytest/issues/4036>`_: The ``item`` parameter of ``pytest_warning_captured`` hook is now documented as deprecated. We realized only after
the ``3.8`` release that this parameter is incompatible with ``pytest-xdist``. the ``3.8`` release that this parameter is incompatible with ``pytest-xdist``.
Our policy is to not deprecate features during bugfix releases, but in this case we believe it makes sense as we are Our policy is to not deprecate features during bug-fix releases, but in this case we believe it makes sense as we are
only documenting it as deprecated, without issuing warnings which might potentially break test suites. This will get only documenting it as deprecated, without issuing warnings which might potentially break test suites. This will get
the word out that hook implementers should not use this parameter at all. the word out that hook implementers should not use this parameter at all.

2
doc/en/development_guide.rst
View File

@ -19,7 +19,7 @@ Branches
We have two long term branches: We have two long term branches:
* ``master``: contains the code for the next bugfix release. * ``master``: contains the code for the next bug-fix release.
* ``features``: contains the code with new features for the next minor release. * ``features``: contains the code with new features for the next minor release.
The official repository usually does not contain topic branches, developers and contributors should create topic The official repository usually does not contain topic branches, developers and contributors should create topic

6
scripts/release.minor.rst
View File

@ -6,7 +6,7 @@ The pytest team is proud to announce the {version} release!
pytest is a mature Python testing tool with more than a 2000 tests pytest is a mature Python testing tool with more than a 2000 tests
against itself, passing on many different interpreters and platforms. against itself, passing on many different interpreters and platforms.
This release contains a number of bugs fixes and improvements, so users are encouraged This release contains a number of bug fixes and improvements, so users are encouraged
to take a look at the CHANGELOG: to take a look at the CHANGELOG:
https://docs.pytest.org/en/latest/changelog.html https://docs.pytest.org/en/latest/changelog.html
@ -15,7 +15,7 @@ For complete documentation, please visit:
https://docs.pytest.org/en/latest/ https://docs.pytest.org/en/latest/
As usual, you can upgrade from pypi via: As usual, you can upgrade from PyPI via:
pip install -U pytest pip install -U pytest
@ -24,4 +24,4 @@ Thanks to all who contributed to this release, among them:
{contributors} {contributors}
Happy testing, Happy testing,
The Pytest Development Team The pytest Development Team