Release Workflow
When it's time to make a new release of Nazara, this procedure should be followed.
1. Update all Version numbers
Make sure to update all version numbers in the following places:
Cargo.tomlNazara.specREADME.md(Add to Compatibility List)docs/src/intro.md(Add to Compatibility List)
1.1 Version Numbers
We generally orient ourselves along the lines of semantic versioning. The following guidelines apply for versioning:
- Patch Versions: Smaller changes/updates/bugfixes without updates to the API client
- Minor Versions: Updates to the API client without major reworks/breaking changes
- Major Versions: Breaking Changes with the API client OR completion of a large feature that significantly impacts Nazara's behaviour or expands scope.
In the end, decisions about versioning are made by the core maintainers. When in doubt, shoot an email to the project owner.
2. Tag New Version
Tag a new version on the latest commit on the main branch.
$ git tag -a v0.1.0_beta.1 -m "v0.1.0_beta.1: Feature X"
$ git push $REMOTE v0.1.0_beta.1
$REMOTE here is the name of the upstream Nazara remote. By default, when cloning upstream, it's origin.
3. Build and Publish to crates.io
We always release to crates.io first.
Publish the newest version of Nazara to crates.io.
$ cargo publish
In order to be able to publish new versions, you must be given permissions to do so first. If the publishing fails, please reach out to the Project Owner.
4. Create a New Release
The next step includes creating a new Release via the VC Web UI.
To do so, follow these steps:
- Select latest tag
- Select previous tag (if not already done automatically)
-
Press "Generate Release Notes" and split into
Added,Fixed,Removedsections as it seems fitting -
Describe the core changes of this release in a short
What's new?section at the top -
Manually build a
.debpackage usingcargo deband attach that and the release binary to the Release for people who want to manually download it - Hit "Create Release"
5. Updating Distribution Packages
-- Coming Soon --