3.1 KiB
3.1 KiB
Summary
Pull Request Check List
- Do not open pull requests from your
main
branch – use a separate branch!- There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
- This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
- Added tests for changed code. Our CI fails if coverage is not 100%.
- New features have been added to our Hypothesis testing strategy.
- Changes or additions to public APIs are reflected in our type stubs (files ending in
.pyi
).- ...and used in the stub test file
tests/typing_example.py
. - If they've been added to
attr/__init__.pyi
, they've also been re-imported inattrs/__init__.pyi
.
- ...and used in the stub test file
- Updated documentation for changed code.
- New functions/classes have to be added to
docs/api.rst
by hand. - Changes to the signatures of
@attr.s()
and@attrs.define()
have to be added by hand too. - Changed/added classes/methods/functions have appropriate
versionadded
,versionchanged
, ordeprecated
directives. The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0. If the next version is the first in the new year, it'll be 23.1.0.- If something changed that affects both
attrs.define()
andattr.s()
, you have to add version directives to both.
- If something changed that affects both
- New functions/classes have to be added to
- Documentation in
.rst
and.md
files is written using semantic newlines. - Changes (and possible deprecations) have news fragments in
changelog.d
. - Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.