Some general guidelines regarding development in pytest for core maintainers and general contributors. Nothing here is set in stone and can’t be changed, feel free to suggest improvements or changes in the workflow.
We have two long term branches:
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.
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.
Here is a list of labels and a brief description mentioning their intent.
Type
Status
Topic
Plugin (internal or external)
OS
Issues specific to a single operating system. Do not use as a means to indicate where an issue originated from, only for problems that happen only in that system.
Temporary
Used to classify issues for limited time, to help find issues related in events for example. They should be removed after they are no longer relevant.
Our current policy for releasing is to aim for a bugfix 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 in that platform.
Install development dependencies in a virtual environment with:
pip3 install -r tasks/requirements.txt
Create a branch release-X.Y.Z with the version for the release.
Ensure your are in a clean work tree.
Generate docs, changelog, announcements and upload a package to your devpi staging server:
invoke generate.pre-release <VERSION> <DEVPI USER> --password <DEVPI PASSWORD>
If --password is not given, it is assumed the user is already logged in devpi. If you don’t have an account, please ask for one.
Open a PR for this branch targeting master.
Test the package
Manual method
Run from multiple machines:
devpi use https://devpi.net/USER/dev
devpi test pytest==VERSION
Check that tests pass for relevant combinations with:
devpi list pytest
CI servers
Configure a repository as per-instructions on devpi-cloud-test to test the package on Travis and AppVeyor. All test environments should pass.
Publish to PyPI:
invoke generate.publish-release <VERSION> <DEVPI USER> <PYPI_NAME>
where PYPI_NAME is the name of pypi.python.org as configured in your ~/.pypirc file for devpi.
After a minor/major release, merge release-X.Y.Z into master and push (or open a PR).