1
0
Fork 0

Adding upstream version 0.5.1.

Signed-off-by: Daniel Baumann <daniel@debian.org>
This commit is contained in:
Daniel Baumann 2025-05-04 22:22:32 +02:00
parent 303fa6e9d8
commit 97e6d74bac
Signed by: daniel
GPG key ID: FBB4F0E80A80222F
110 changed files with 12006 additions and 0 deletions

42
CONTRIBUTING.md Normal file
View file

@ -0,0 +1,42 @@
# OpenAPI Pydantic Contribution Guide
We welcome all contributions!
## Issues
Questions, feature requests and bug reports are all welcome as issues. When raising a bug or
question, please include as much information as possible including the specific version you
are using.
## Pull Requests
It should be very simple to get started and open a pull request, however for anything non-trivial
please open an issue to discuss your intended change _before_ creating your PR. This avoids wasting
time by ensuring that your changes will be accepted with fewer revisions down the line!
### Local Development
A [devcontainer](https://code.visualstudio.com/docs/devcontainers/containers) configuration is provided in the repo to get your environment setup automatically. Alternatively you can install [tox](https://tox.wiki/en/latest/) and [poetry](https://python-poetry.org/) manually.
### Testing
Please ensure all changes have good test coverage and are formatted correctly. You can run the test
suite and linters using [tox](https://tox.wiki/en/latest/) - just run `tox` from the root of this
repo to run the checks. These will also be run automatically in CI once your PR is opened. Don't
worry about testing against every Ptyhon version - the CI action will do this for you!
### Tagging
When your PR is ready, please tag it with the appropriate tags: one of `feature`, `change`, `fix`,
as well as `breaking` if you've introduced backwards-incompatible changes to the public API or
behaviour.
## Review
We'll review your PR as soon as possible - either approving or requesting changes. Once the PR is
approved, it will be merged into main and cut into the next release.
## Releases
The release schedule is not set in stone and will depend on the number of changes in flight, but where possible we'll look to cut a release with your changes as soon as possible. Once a new version is tagged,
a package version is uploaded to PyPI automatically.