port the rest of the scripts/docs over to the main branch
This commit is contained in:
Ronny Pfannschmidt
parent
35df3e68d5
commit
ff6d5ae278
|
|
@ -4,4 +4,4 @@ Changelog
|
|||
|
||||
The pytest CHANGELOG is located `here <https://docs.pytest.org/en/stable/changelog.html>`__.
|
||||
|
||||
The source document can be found at: https://github.com/pytest-dev/pytest/blob/master/doc/en/changelog.rst
|
||||
The source document can be found at: https://github.com/pytest-dev/pytest/blob/main/doc/en/changelog.rst
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ Here is a simple overview, with pytest-specific bits:
|
|||
|
||||
$ git clone git@github.com:YOUR_GITHUB_USERNAME/pytest.git
|
||||
$ cd pytest
|
||||
# now, create your own branch off "master":
|
||||
# now, create your own branch off "main":
|
||||
|
||||
$ git checkout -b your-bugfix-branch-name main
|
||||
|
||||
|
|
@ -387,15 +387,15 @@ Suppose for example that the latest release was 1.2.3, and you want to include
|
|||
a bug fix in 1.2.4 (check https://github.com/pytest-dev/pytest/releases for the
|
||||
actual latest release). The procedure for this is:
|
||||
|
||||
#. First, make sure the bug is fixed the ``master`` branch, with a regular pull
|
||||
#. First, make sure the bug is fixed the ``main`` branch, with a regular pull
|
||||
request, as described above. An exception to this is if the bug fix is not
|
||||
applicable to ``master`` anymore.
|
||||
applicable to ``main`` anymore.
|
||||
|
||||
#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the master PR number here
|
||||
#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the main PR number here
|
||||
|
||||
#. Locate the merge commit on the PR, in the *merged* message, for example:
|
||||
|
||||
nicoddemus merged commit 0f8b462 into pytest-dev:master
|
||||
nicoddemus merged commit 0f8b462 into pytest-dev:main
|
||||
|
||||
#. ``git cherry-pick -x -m1 REVISION`` # use the revision you found above (``0f8b462``).
|
||||
|
||||
|
|
@ -408,7 +408,7 @@ actual latest release). The procedure for this is:
|
|||
Who does the backporting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As mentioned above, bugs should first be fixed on ``master`` (except in rare occasions
|
||||
As mentioned above, bugs should first be fixed on ``main`` (except in rare occasions
|
||||
that a bug only happens in a previous release). So who should do the backport procedure described
|
||||
above?
|
||||
|
||||
|
|
@ -417,8 +417,8 @@ above?
|
|||
2. However, often the merge is done by another maintainer, in which case it is nice of them to
|
||||
do the backport procedure if they have the time.
|
||||
3. For bugs submitted by non-maintainers, it is expected that a core developer will to do
|
||||
the backport, normally the one that merged the PR on ``master``.
|
||||
4. If a non-maintainers notices a bug which is fixed on ``master`` but has not been backported
|
||||
the backport, normally the one that merged the PR on ``main``.
|
||||
4. If a non-maintainers notices a bug which is fixed on ``main`` but has not been backported
|
||||
(due to maintainers forgetting to apply the *needs backport* label, or just plain missing it),
|
||||
they are also welcome to open a PR with the backport. The procedure is simple and really
|
||||
helps with the maintenance of the project.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
:target: https://github.com/pytest-dev/pytest/actions?query=workflow%3Amain
|
||||
|
||||
.. image:: https://results.pre-commit.ci/badge/github/pytest-dev/pytest/main.svg
|
||||
:target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/master
|
||||
:target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/main
|
||||
:alt: pre-commit.ci status
|
||||
|
||||
.. image:: https://img.shields.io/badge/code%20style-black-000000.svg
|
||||
|
|
|
|||
|
|
@ -32,10 +32,10 @@ and notify it as a comment in the issue.
|
|||
Minor releases
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
1. Create a new maintenance branch from ``master``::
|
||||
1. Create a new maintenance branch from ``main``::
|
||||
|
||||
git fetch --all
|
||||
git branch 5.2.x upstream/master
|
||||
git branch 5.2.x upstream/main
|
||||
git push upstream 5.2.x
|
||||
|
||||
2. Open a new issue and add this comment to the body::
|
||||
|
|
@ -48,10 +48,10 @@ notify it as a comment in the issue.
|
|||
Major and release candidates
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Create a new maintenance branch from ``master``::
|
||||
1. Create a new maintenance branch from ``main``::
|
||||
|
||||
git fetch --all
|
||||
git branch 6.0.x upstream/master
|
||||
git branch 6.0.x upstream/main
|
||||
git push upstream 6.0.x
|
||||
|
||||
2. For a **major release**, open a new issue and add this comment in the body::
|
||||
|
|
@ -66,7 +66,7 @@ The automated workflow will publish a PR for a branch ``release-6.0.0`` and
|
|||
notify it as a comment in the issue.
|
||||
|
||||
At this point on, this follows the same workflow as other maintenance branches: bug-fixes are merged
|
||||
into ``master`` and ported back to the maintenance branch, even for release candidates.
|
||||
into ``main`` and ported back to the maintenance branch, even for release candidates.
|
||||
|
||||
**A note about release candidates**
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ to be executed on that platform.
|
|||
To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
|
||||
|
||||
#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from
|
||||
``upstream/master`` and push it to ``upstream``.
|
||||
``upstream/main`` and push it to ``upstream``.
|
||||
|
||||
#. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
|
||||
|
||||
|
|
@ -114,18 +114,18 @@ Both automatic and manual processes described above follow the same steps from t
|
|||
|
||||
#. Merge the PR.
|
||||
|
||||
#. Cherry-pick the CHANGELOG / announce files to the ``master`` branch::
|
||||
#. Cherry-pick the CHANGELOG / announce files to the ``main`` branch::
|
||||
|
||||
git fetch --all --prune
|
||||
git checkout origin/master -b cherry-pick-release
|
||||
git checkout origin/main -b cherry-pick-release
|
||||
git cherry-pick -x -m1 upstream/MAJOR.MINOR.x
|
||||
|
||||
#. Open a PR for ``cherry-pick-release`` and merge it once CI passes. No need to wait for approvals if there were no conflicts on the previous step.
|
||||
|
||||
#. For major and minor releases, tag the release cherry-pick merge commit in master with
|
||||
#. For major and minor releases, tag the release cherry-pick merge commit in main with
|
||||
a dev tag for the next feature release::
|
||||
|
||||
git checkout master
|
||||
git checkout main
|
||||
git pull
|
||||
git tag MAJOR.{MINOR+1}.0.dev0
|
||||
git push git@github.com:pytest-dev/pytest.git MAJOR.{MINOR+1}.0.dev0
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered manually in
|
|||
tab of the repository.
|
||||
|
||||
The user will need to enter the base branch to start the release from (for example
|
||||
``6.1.x`` or ``master``) and if it should be a major release.
|
||||
``6.1.x`` or ``main``) and if it should be a major release.
|
||||
|
||||
The appropriate version will be obtained based on the given branch automatically.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered by comments
|
|||
in issues.
|
||||
|
||||
This script is started by the `release-on-comment.yml` workflow, which always executes on
|
||||
`master` and is triggered by two comment related events:
|
||||
`main` and is triggered by two comment related events:
|
||||
|
||||
* https://help.github.com/en/actions/reference/events-that-trigger-workflows#issue-comment-event-issue_comment
|
||||
* https://help.github.com/en/actions/reference/events-that-trigger-workflows#issues-event-issues
|
||||
|
|
@ -16,8 +16,8 @@ The payload must contain a comment with a phrase matching this pseudo-regular ex
|
|||
|
||||
Then the appropriate version will be obtained based on the given branch name:
|
||||
|
||||
* a major release from master if "major" appears in the phrase in that position
|
||||
* a feature or bug fix release from master (based if there are features in the current changelog
|
||||
* a major release from main if "major" appears in the phrase in that position
|
||||
* a feature or bug fix release from main (based if there are features in the current changelog
|
||||
folder)
|
||||
* a bug fix from a maintenance branch
|
||||
|
||||
|
|
@ -230,11 +230,11 @@ def find_next_version(base_branch: str, is_major: bool) -> str:
|
|||
breaking = list(changelog.glob("*.breaking.rst"))
|
||||
is_feature_release = features or breaking
|
||||
|
||||
if is_feature_release and base_branch != "master":
|
||||
if is_feature_release and base_branch != "main":
|
||||
msg = dedent(
|
||||
f"""
|
||||
Found features or breaking changes in `{base_branch}`, and feature releases can only be
|
||||
created from `master`:
|
||||
created from `main`:
|
||||
"""
|
||||
)
|
||||
msg += "\n".join(f"* `{x.name}`" for x in sorted(features + breaking))
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ def install_importhook(config: Config) -> rewrite.AssertionRewritingHook:
|
|||
|
||||
def pytest_collection(session: "Session") -> None:
|
||||
# This hook is only called when test modules are collected
|
||||
# so for example not in the master process of pytest-xdist
|
||||
# so for example not in the managing process of pytest-xdist
|
||||
# (which does not collect test modules).
|
||||
assertstate = session.config._store.get(assertstate_key, None)
|
||||
if assertstate:
|
||||
|
|
|
|||
Loading…
Reference in New Issue