Hello! 👋
We're happy that you're here, and appreciate your interest in making F1 API a better tool. This document is supposed to give you a helping hand in getting started.
In the unfortunate (but not unlikely) event that you found a bug in F1 API, it is best to file a bug report in our issue tracker. Please answer all questions in the form, and be as detailed as possible. This helps us investigate and fix the issue.
If there is something missing in F1 API that you think should be there, we'd love to here from you. Before investing any time writing us, though, have a look at the issues in our issue tracker. Someone else might have already requested the same or a similar feature, and in that case it's best to join this discussion instead of starting a new one.
If you don't find anything, make sure to also check the closed issues. The feature may have already been implemented, but not yet released.
Please be aware that while we appreciate your feature requests, we might not be able to implement it in F1 API. It is our responsibility to make sure F1 API is well maintained, and as a small team this is only possible if the library stays small.
When working on a bug or a feature, make sure to follow the style guidelines, write good documentation, and test your code thoroughly. The style guidelines are automatically checked and enforced whenever you commit code. And as a rule of thumb, every function should have a unit test.
Also make sure to write proper Git commit messages. We're big fans the blog post How to write a Git commit message, and the rules it introduces.
When your code is ready, open a pull request. You can also open a draft pull request before, and ask for early feedback. We will review the pull request, and suggest or require changes. Since we are responsible for the code once it is merged, we take this very seriously. We want to be able to support it in the best way possible, and that requires us to fully understand it.
Only maintainers of Nord SDK can cut a new release. The process is largely automated to avoid errors and mistakes. These are the steps necessary to create a new release and publish it to crates.io:
-
Create a new branch for the release.
git checkout master git checkout -b cut-release
-
Run cargo-release to prepare the release. This sets the version, updates the changelog, and tags the commit.
cargo release [patch|minor|major]
-
Push the branch to GitHub, create a pull request, and wait for the checks to pass.
-
Go to the releases and create a release for the new version. Copy the relevant section from the changelog into the release message, and name the release after the version. When saving the release, a GitHub action is started that publishes the version to crates.io.