|
1 | 1 | # Contributing to B2 Python SDK |
2 | 2 |
|
3 | | -We encourage outside contributors to perform changes on our codebase. Many such changes have been merged already. In order to make it easier to contribute, core developers of this project: |
| 3 | +We encourage outside contributors to perform changes on our codebase. Many such changes have been merged already. |
| 4 | +In order to make it easier to contribute, core developers of this project: |
4 | 5 |
|
5 | 6 | * provide guidance (through the issue reporting system) |
6 | 7 | * provide tool assisted code review (through the Pull Request system) |
7 | 8 | * maintain a set of unit tests |
8 | 9 | * maintain a set of integration tests (run with a production cloud) |
9 | 10 | * maintain development automation tools using [nox](https://github.com/theacodes/nox) that can easily: |
10 | | - * format the code using [yapf](https://github.com/google/yapf) |
| 11 | + * format the code using [yapf](https://github.com/google/yapf) and [ruff](https://github.com/astral-sh/ruff) |
11 | 12 | * runs linters to find subtle/potential issues with maintainability |
12 | 13 | * run the test suite on multiple Python versions using [pytest](https://github.com/pytest-dev/pytest) |
13 | 14 | * maintain Continuous Integration (by using GitHub Actions) that: |
14 | 15 | * runs all sorts of linters |
15 | 16 | * checks if the Python distribution can be built |
16 | | - * runs all tests on a matrix of 6 versions of Python (including pypy) and 3 operating systems (Linux, Mac OS X and Windows) |
| 17 | + * runs all tests on a matrix of 6 versions of Python (including pypy) and 3 operating systems |
| 18 | + (Linux, Mac OS X and Windows) |
17 | 19 | * checks if the documentation can be built properly |
18 | 20 | * maintain other Continuous Integration tools (coverage tracker) |
19 | 21 |
|
| 22 | +## Versioning |
| 23 | + |
| 24 | +This package's versions adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and the versions are |
| 25 | +established by reading git tags, i.e. no code or manifest file changes are required when working on PRs. |
| 26 | + |
| 27 | +## Changelog |
| 28 | + |
| 29 | +Each PR needs to have at least one changelog (aka news) item added. This is done by creating files in `changelog.d`. |
| 30 | +`towncrier` is used for compiling these files into [CHANGELOG.md](CHANGELOG.md). There are several types of changes |
| 31 | +(news): |
| 32 | + |
| 33 | +1. fixed |
| 34 | +2. changed |
| 35 | +3. added |
| 36 | +4. deprecated |
| 37 | +5. removed |
| 38 | +6. infrastructure |
| 39 | +7. doc |
| 40 | + |
| 41 | + |
| 42 | +The `changelog.d` file name convention is: |
| 43 | + |
| 44 | +1. If the PR closes a github issue: `{issue_number}.{type}.md` e.g. `157.fixed.md`. Note that the |
| 45 | + change description still has to be complete, linking an issue is just there for convenience, a change like |
| 46 | + `fixed #157` will not be accepted. |
| 47 | +2. If the PR is not related to a github issue: `+{unique_string}.{type}.md` e.g. `+foobar.fixed.md`. |
| 48 | + |
| 49 | +These files can either be created manually, or using `towncrier` e.g. |
| 50 | + |
| 51 | + towncrier create -c 'write your description here' 157.fixed.md |
| 52 | + |
| 53 | +`towncrier create` also takes care of duplicates automatically (if there is more than 1 news fragment of one type |
| 54 | +for a given github issue). |
| 55 | + |
20 | 56 | ## Developer Info |
21 | 57 |
|
22 | 58 | You'll need to have [nox](https://github.com/theacodes/nox) installed: |
|
0 commit comments