Switch to new git workflow

Co-Authored-By: Daniel Hahler <[email protected]>

Author: bluetech

.github/PULL_REQUEST_TEMPLATE.md

@@ -3,8 +3,6 @@ Thanks for submitting a PR, your contribution is really appreciated!
 
 Here is a quick checklist that should be present in PRs.
 
-- [ ] Target the `master` branch for bug fixes, documentation updates and trivial changes.
-- [ ] Target the `features` branch for new features, improvements, and removals/deprecations.
 - [ ] Include documentation when adding new features.
 - [ ] Include new tests or update existing tests when applicable.
 

.github/workflows/main.yml

@@ -10,12 +10,14 @@ on:
   push:
     branches:
       - master
+      - "[0-9]+.[0-9]+.x"
     tags:
       - "*"
 
   pull_request:
     branches:
       - master
+      - "[0-9]+.[0-9]+.x"
 
 jobs:
   build:

.pre-commit-config.yaml

@@ -47,7 +47,7 @@ repos:
     -   id: rst
         name: rst
         entry: rst-lint --encoding utf-8
-        files: ^(HOWTORELEASE.rst|README.rst|TIDELIFT.rst)$
+        files: ^(RELEASING.rst|README.rst|TIDELIFT.rst)$
         language: python
         additional_dependencies: [pygments, restructuredtext_lint]
     -   id: changelogs-rst

.travis.yml

@@ -82,6 +82,4 @@ notifications:
 branches:
   only:
     - master
-    - features
-    - 4.6-maintenance
-    - /^\d+(\.\d+)+$/
+    - /^\d+\.\d+\.x$/

CONTRIBUTING.rst

@@ -166,8 +166,6 @@ 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 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``::
 
@@ -204,14 +202,10 @@ Here is a simple overview, with pytest-specific bits:
 
     $ git clone [email protected]:YOUR_GITHUB_USERNAME/pytest.git
     $ cd pytest
-    # now, to fix a bug create your own branch off "master":
+    # now, create your own branch off "master":
 
         $ git checkout -b your-bugfix-branch-name master
 
-    # or to instead add a feature create your own branch off "features":
-
-        $ git checkout -b your-feature-branch-name features
-
    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,8 +288,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 bug fix
-    base: features        # if it's a feature
+    base: master
 
 
 Writing Tests

HOWTORELEASE.rst renamed to RELEASING.rst

@@ -10,40 +10,38 @@ taking a lot of time to make a new one.
     pytest releases must be prepared on **Linux** because the docs and examples expect
     to be executed on that platform.
 
-#. Create a branch ``release-X.Y.Z`` with the version for the release.
+To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
 
-   * **maintenance releases**: from ``4.6-maintenance``;
+#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from the
+   latest ``master`` and push it to the ``pytest-dev/pytest`` repo.
 
-   * **patch releases**: from the latest ``master``;
+#. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
 
-   * **minor releases**: from the latest ``features``; then merge with the latest ``master``;
-
-   Ensure your are in a clean work tree.
+   Ensure your are updated and in a clean working tree.
 
 #. Using ``tox``, generate docs, changelog, announcements::
 
-    $ tox -e release -- <VERSION>
+    $ tox -e release -- MAJOR.MINOR.PATCH
 
    This will generate a commit with all the changes ready for pushing.
 
-#. Open a PR for this branch targeting ``master`` (or ``4.6-maintenance`` for
-   maintenance releases).
+#. Open a PR for the ``release-MAJOR.MINOR.PATCH`` branch targeting ``MAJOR.MINOR.x``.
 
-#. After all tests pass and the PR has been approved, publish to PyPI by pushing the tag::
+#. After all tests pass and the PR has been approved, tag the release commit
+   in the ``MAJOR.MINOR.x`` branch and push it. This will publish to PyPI::
 
-     git tag <VERSION>
-     git push [email protected]:pytest-dev/pytest.git <VERSION>
+     git tag MAJOR.MINOR.PATCH
+     git push [email protected]:pytest-dev/pytest.git MAJOR.MINOR.PATCH
 
    Wait for the deploy to complete, then make sure it is `available on PyPI <https://pypi.org/project/pytest>`_.
 
 #. Merge the PR.
 
-#. If this is a maintenance release, cherry-pick the CHANGELOG / announce
-   files to the ``master`` branch::
+#. Cherry-pick the CHANGELOG / announce files to the ``master`` branch::
 
        git fetch --all --prune
-       git checkout origin/master -b cherry-pick-maintenance-release
-       git cherry-pick --no-commit -m1 origin/4.6-maintenance
+       git checkout origin/master -b cherry-pick-release
+       git cherry-pick --no-commit -m1 origin/MAJOR.MINOR.x
        git checkout origin/master -- changelog
        git commit  # no arguments
 

doc/en/development_guide.rst

@@ -57,4 +57,4 @@ Issues created at those events should have other relevant labels added as well.
 Those labels should be removed after they are no longer relevant.
 
 
-.. include:: ../../HOWTORELEASE.rst
+.. include:: ../../RELEASING.rst

doc/en/py27-py34-deprecation.rst

@@ -29,9 +29,9 @@ Maintenance of 4.6.X versions
 -----------------------------
 
 Until January 2020, the pytest core team ported many bug-fixes from the main release into the
-``4.6-maintenance`` branch, with several 4.6.X releases being made along the year.
+``4.6.x`` branch, with several 4.6.X releases being made along the year.
 
-From now on, the core team will **no longer actively backport patches**, but the ``4.6-maintenance``
+From now on, the core team will **no longer actively backport patches**, but the ``4.6.x``
 branch will continue to exist so the community itself can contribute patches.
 
 The core team will be happy to accept those patches, and make new 4.6.X releases **until mid-2020**
@@ -74,22 +74,22 @@ Please follow these instructions:
 
 #. ``git fetch --all --prune``
 
-#. ``git checkout origin/4.6-maintenance -b backport-XXXX`` # use the PR number here
+#. ``git checkout origin/4.6.x -b backport-XXXX`` # use the PR number here
 
 #. Locate the merge commit on the PR, in the *merged* message, for example:
 
     nicoddemus merged commit 0f8b462 into pytest-dev:features
 
 #. ``git cherry-pick -m1 REVISION`` # use the revision you found above (``0f8b462``).
 
-#. Open a PR targeting ``4.6-maintenance``:
+#. Open a PR targeting ``4.6.x``:
 
    * Prefix the message with ``[4.6]`` so it is an obvious backport
    * Delete the PR body, it usually contains a duplicate commit message.
 
 **Providing new PRs to 4.6**
 
-Fresh pull requests to ``4.6-maintenance`` will be accepted provided that
+Fresh pull requests to ``4.6.x`` will be accepted provided that
 the equivalent code in the active branches does not contain that bug (for example, a bug is specific
 to Python 2 only).