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

adjust RELEASE.md #924

Merged
merged 1 commit into from
May 23, 2024
Merged

adjust RELEASE.md #924

Show file tree
Hide file tree
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 @@ -30,11 +30,11 @@ The SRI repo holds two principal branches with an infinite lifetime:
- `main`
- `dev`

We consider `main` to be the branch where the source code of `HEAD` always reflects a production-ready state.
We consider `main` to be the branch where the source code of `HEAD` always reflects the latest release.

We consider `dev` to be the branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release.
We consider `dev` to be the branch where the source code of `HEAD` always reflects the latest changes in the development cycle.

The SRI team will decide the appropriate time when the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR` and/or `MINOR`.
The SRI team will decide the appropriate time when the changes to `dev` are merged back into `main` and then tagged with a release number while bumping `MAJOR`, `MINOR`, or `PATCH`.

## Feature Branches

Expand All @@ -48,8 +48,8 @@ New features are developed into separate branches that only live in the contribu

Bugs are patched into separate branches that only live in the contributor's forks.

- branch off from: `main`
- merge back into: `main` + `dev`
- branch off from: `dev`
- merge back into: `dev`
- naming convention: `patch-x`, where `x` describes the bug/patch

# Releasing Roles Binaries
Expand All @@ -72,7 +72,7 @@ If a crate is not updated successfully, the step will fail, but since all steps

Since steps can fail, the output of the action must be manually checked.

Every PR to `main` (either coming from `dev`, or a patch) needs to increase the version of whatever crate it is touching. Otherwise, we will mess up the dependency chain of whoever is fetching from crates.io
Every PR to `main` needs to increase the version of whatever crate it is touching. Otherwise, we will mess up the dependency chain of whoever is fetching from crates.io

Manually running `cargo release` in the various workspaces helps to prepare the version number before the releases are published.

Expand Down
Binary file modified git-branching.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading