diff options
| -rw-r--r-- | .github/PULL_REQUEST_TEMPLATE.md | 2 | ||||
| -rw-r--r-- | .github/workflows/main.yml | 2 | ||||
| -rw-r--r-- | .pre-commit-config.yaml | 2 | ||||
| -rw-r--r-- | .travis.yml | 4 | ||||
| -rw-r--r-- | CONTRIBUTING.rst | 11 | ||||
| -rw-r--r-- | RELEASING.rst (renamed from HOWTORELEASE.rst) | 30 | ||||
| -rw-r--r-- | doc/en/development_guide.rst | 2 | ||||
| -rw-r--r-- | doc/en/py27-py34-deprecation.rst | 10 |
8 files changed, 26 insertions, 37 deletions
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 2e221f73e..d189f7869 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.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. - [X] Allow maintainers to push and squash when merging my commits. Please uncheck this if you prefer to squash the commits yourself. diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 242c2eb83..a8a9c527b 100644 --- a/.github/workflows/main.yml +++ b/.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: diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 8894c713f..694dedc93 100644 --- a/.pre-commit-config.yaml +++ b/.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 diff --git a/.travis.yml b/.travis.yml index 32ab7f6fd..60be90e28 100644 --- a/.travis.yml +++ b/.travis.yml @@ -57,6 +57,4 @@ notifications: branches: only: - master - - features - - 4.6-maintenance - - /^\d+(\.\d+)+$/ + - /^\d+\.\d+\.x$/ diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 0474fa3a3..57921de2f 100644 --- a/CONTRIBUTING.rst +++ b/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 git@github.com: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 diff --git a/HOWTORELEASE.rst b/RELEASING.rst index b6b596ba2..323e26cdf 100644 --- a/HOWTORELEASE.rst +++ b/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 git@github.com:pytest-dev/pytest.git <VERSION> + git tag MAJOR.MINOR.PATCH + git push git@github.com: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 diff --git a/doc/en/development_guide.rst b/doc/en/development_guide.rst index 31fc2c438..2f9762f2a 100644 --- a/doc/en/development_guide.rst +++ b/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 diff --git a/doc/en/py27-py34-deprecation.rst b/doc/en/py27-py34-deprecation.rst index f09ee3aa4..f2d6b540d 100644 --- a/doc/en/py27-py34-deprecation.rst +++ b/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,7 +74,7 @@ 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: @@ -82,14 +82,14 @@ Please follow these instructions: #. ``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). |