From ff6d5ae278f374cc9343f7e589e05e162158e2cd Mon Sep 17 00:00:00 2001 From: Ronny Pfannschmidt Date: Thu, 18 Mar 2021 22:13:12 +0100 Subject: [PATCH] port the rest of the scripts/docs over to the main branch --- CHANGELOG.rst | 2 +- CONTRIBUTING.rst | 16 ++++++++-------- README.rst | 2 +- RELEASING.rst | 20 ++++++++++---------- scripts/prepare-release-pr.py | 2 +- scripts/release-on-comment.py | 10 +++++----- src/_pytest/assertion/__init__.py | 2 +- 7 files changed, 27 insertions(+), 27 deletions(-) diff --git a/CHANGELOG.rst b/CHANGELOG.rst index 3865f250c..481f27781 100644 --- a/CHANGELOG.rst +++ b/CHANGELOG.rst @@ -4,4 +4,4 @@ Changelog The pytest CHANGELOG is located `here `__. -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 diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index ba783d5c1..5855d4791 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.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. diff --git a/README.rst b/README.rst index d0014e8bf..ee11a2d60 100644 --- a/README.rst +++ b/README.rst @@ -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 diff --git a/RELEASING.rst b/RELEASING.rst index 9ec2b069c..600c12539 100644 --- a/RELEASING.rst +++ b/RELEASING.rst @@ -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 diff --git a/scripts/prepare-release-pr.py b/scripts/prepare-release-pr.py index 296de46ea..5ba174f23 100644 --- a/scripts/prepare-release-pr.py +++ b/scripts/prepare-release-pr.py @@ -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. diff --git a/scripts/release-on-comment.py b/scripts/release-on-comment.py index f8af9c0fc..3f4c1ed57 100644 --- a/scripts/release-on-comment.py +++ b/scripts/release-on-comment.py @@ -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)) diff --git a/src/_pytest/assertion/__init__.py b/src/_pytest/assertion/__init__.py index a18cf198d..fd79f34cc 100644 --- a/src/_pytest/assertion/__init__.py +++ b/src/_pytest/assertion/__init__.py @@ -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: