Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

global release docs #1154

Merged
merged 1 commit into from
Sep 4, 2024
Merged

global release docs #1154

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,6 @@ Things to take into account while writing a changelog:
- Breaking changes.
- Notable changes.


## Release Process

Try to constrain each development cycle to a fixed time period, after which a
Expand All @@ -35,18 +34,19 @@ Usually the release process is as follows:
5. Create a new tag for the release branch.
6. Publish the release.


## Versioning

Protocol and Utils crates follow SemVer 2.0.0. The version number is stored in
Crates under `protocols` and `utils` workspaces follow SemVer 2.0.0. The version number is stored in
the `Cargo.toml` file of each crate. If a breaking change is introduced to one
of the crates, the version number must be updated accordingly, otherwise a
SemVer CI check would fail. Note that this does not apply to the `roles` and
other crates in the repository.

The general SRI version does not follow any SemVer rules. You can track the
releases on Github Releases in the repository.

The global repository releases follow `X.Y.Z`, which is changed under some subjective criteria:
- Changes in `roles` are not taken into account. `roles` crates are still in Proof of Concept phase and not production ready.
- If a release includes only bug fixes in `protocols` and/or `utils`, then `Z` is bumped.
- If a release includes breaking and/or non-breaking changes to `protocols` and/or `utils`, then `Y` is bumped.
- If a release marks a milestone i.e., `protocols` is reaching a new maturity level, then `X` is bumped.

## Tags and Branches

Expand Down
Loading