Merge pull request #6549 from blueyed/fix-release-minor
doc: minor fixes for the release process
This commit is contained in:
Daniel Hahler
GitHub
commit
79d00ab35a
|
|
@ -166,7 +166,7 @@ Short version
|
|||
|
||||
#. Fork the repository.
|
||||
#. Enable and install `pre-commit <https://pre-commit.com>`_ to ensure style-guides and code checks are followed.
|
||||
#. Target ``master`` for bugfixes and doc changes.
|
||||
#. Target ``master`` for bug fixes and doc changes.
|
||||
#. Target ``features`` for new features or functionality changes.
|
||||
#. Follow **PEP-8** for naming and `black <https://github.com/psf/black>`_ for formatting.
|
||||
#. Tests are run using ``tox``::
|
||||
|
|
@ -212,7 +212,7 @@ Here is a simple overview, with pytest-specific bits:
|
|||
|
||||
$ git checkout -b your-feature-branch-name features
|
||||
|
||||
Given we have "major.minor.micro" version numbers, bugfixes will usually
|
||||
Given we have "major.minor.micro" version numbers, bug fixes will usually
|
||||
be released in micro releases whereas features will be released in
|
||||
minor releases and incompatible changes in major releases.
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ Here is a simple overview, with pytest-specific bits:
|
|||
compare: your-branch-name
|
||||
|
||||
base-fork: pytest-dev/pytest
|
||||
base: master # if it's a bugfix
|
||||
base: master # if it's a bug fix
|
||||
base: features # if it's a feature
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
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
|
||||
taking a lot of time to make a new one.
|
||||
|
||||
.. important::
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
* ``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.
|
||||
* ``deprecation``: feature deprecation.
|
||||
* ``removal``: feature removal.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
the word out that hook implementers should not use this parameter at all.
|
||||
|
||||
|
|
@ -5380,7 +5380,7 @@ time or change existing behaviors in order to make them less surprising/more use
|
|||
Thanks Daniel Grunwald for the report and Bruno Oliveira for the PR.
|
||||
|
||||
- (experimental) adapt more SEMVER style versioning and change meaning of
|
||||
master branch in git repo: "master" branch now keeps the bugfixes, changes
|
||||
master branch in git repo: "master" branch now keeps the bug fixes, changes
|
||||
aimed for micro releases. "features" branch will only be released
|
||||
with minor or major pytest releases.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ 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.
|
||||
|
||||
The official repository usually does not contain topic branches, developers and contributors should create topic
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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:
|
||||
|
||||
https://docs.pytest.org/en/latest/changelog.html
|
||||
|
|
@ -15,7 +15,7 @@ For complete documentation, please visit:
|
|||
|
||||
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
|
||||
|
||||
|
|
@ -24,4 +24,4 @@ Thanks to all who contributed to this release, among them:
|
|||
{contributors}
|
||||
|
||||
Happy testing,
|
||||
The Pytest Development Team
|
||||
The pytest Development Team
|
||||
|
|
|
|||
Loading…
Reference in New Issue