Sylvia welcomes contributions from everyone in the form of suggestions, bug reports, pull requests, and feedback. This document gives some guidance if you are thinking of helping us.
When reporting a bug or asking for help, please include enough details so that the people helping you can reproduce the behavior you are seeing. For some tips on how to approach this, read about how to produce a Minimal, Complete, and Verifiable example.
When making a feature request, please clarify what problem you intend to solve with the feature, any ideas for how Sylvia could support solving that problem, any possible alternatives, and any disadvantages.
Before submitting a pull request, please make sure that the following checks pass:
cargo test && cargo fmt --check && cargo clippy --all-features -- -D warningsIf anything does not pass, typically, it will be easier to iterate and fix it locally than waiting for the CI servers to run tests for you.
You also have to run the tests in the example directory if your pull request affected the sylvia-derive crate:
cd examples && cargo testSylvia requires the commit messages to follow the Conventional Commits specification. This convention makes it easier to understand the changes in the project and to automate the release process.
Ideally, the commit message should also reference the issue number it aims to fix.
Supported headers are:
- feat
- fix
- revert
- docs
- test
- refactor
- chore
- build
feat: Support new type of message (#123)
Additional valuable information about added functionality in the commit.
Sylvia uses the release-plz GitHub action to automate the release process. Instead of manually running cargo publish, merge the automatic PR generated by this action, which will take care of the rest.
Sylvia follows the Semantic Versioning scheme.