Development Guide

Some general guidelines regarding development in pytest for maintainers and contributors. Nothing here is set in stone and can’t be changed, feel free to suggest improvements or changes in the workflow.

Code Style

Branches

We have two long term branches:

  • 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 branches in their own forks.

Exceptions can be made for cases where more than one contributor is working on the same topic or where it makes sense to use some automatic capability of the main repository, such as automatic docs from readthedocs for a branch dealing with documentation refactoring.

Issues

Any question, feature, bug or proposal is welcome as an issue. Users are encouraged to use them whenever they need.

GitHub issues should use labels to categorize them. Labels should be created sporadically, to fill a niche; we should avoid creating labels just for the sake of creating them.

Each label should include a description in the GitHub’s interface stating its purpose.

Labels are managed using labels. All the labels in the repository are kept in .github/labels.toml, so any changes should be via PRs to that file. After a PR is accepted and merged, one of the maintainers must manually synchronize the labels file with the GitHub repository.

Temporary labels

To classify issues for a special event it is encouraged to create a temporary label. This helps those involved to find the relevant issues to work on. Examples of that are sprints in Python events or global hacking events.

  • temporary: EP2017 sprint: candidate issues or PRs tackled during the EuroPython 2017

Issues created at those events should have other relevant labels added as well.

Those labels should be removed after they are no longer relevant.

Release Procedure

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 on that platform.

To release a version MAJOR.MINOR.PATCH, follow these steps:

  1. 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.

  2. Create a branch release-MAJOR.MINOR.PATCH from the MAJOR.MINOR.x branch.

    Ensure your are updated and in a clean working tree.

  3. Using tox, generate docs, changelog, announcements:

    $ tox -e release -- MAJOR.MINOR.PATCH

    This will generate a commit with all the changes ready for pushing.

  4. Open a PR for the release-MAJOR.MINOR.PATCH branch targeting MAJOR.MINOR.x.

  5. 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 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.

  6. Merge the PR.

  7. Cherry-pick the CHANGELOG / announce files to the master branch:

    git fetch --all --prune
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

  8. Send an email announcement with the contents from:

    doc/en/announce/release-<VERSION>.rst

    To the following mailing lists:

    And announce it on Twitter with the #pytest hashtag.