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

Remove odh-manifests references, minor formatting #665

Merged
merged 1 commit into from
Jun 20, 2024
Merged

Remove odh-manifests references, minor formatting #665

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
14 changes: 8 additions & 6 deletions docs/release/release_workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,16 +18,20 @@ DSPO and DSP versioning is tied together, and DSP `MAJOR` versions are tied to [
> it is likely to quickly become incompatible with any specific tags/shas that are hardcoded.

## Pre-requisites

Need GitHub repo admin permissions for DSPO and DSP repos.

## Release workflow

Steps required for performing releases for `MAJOR`, `MINOR`, or `PATCH` vary depending on type.

### MAJOR Releases

Given that `MAJOR` releases often contain large scale, api breaking, changes. It is likely the release process will vary
between each `MAJOR` release. As such, each `MAJOR` release should have a specifically catered strategy.

### MINOR Releases

Let `x.y.z` be the `latest` release that is highest DSPO/DSP version.

Steps on how to release `x.y+1.z`
Expand All @@ -45,11 +49,8 @@ Steps on how to release `x.y+1.z`
6. Create a tag release for `x.y+1.z` in DSPO and DSP (e.g. `v1.3.0`)
7. Add any manifest changes to ODH manifests repo using the [ODH sync workflow]

**Downstream Specifics**

Downstream maintainers of DSP should forward any manifest changes to their odh-manifests downstream

### PATCH Releases

DSP supports bug/security fixes for versions that are at most 1 `MINOR` versions behind the latest `MINOR` release.
For example, if `v1.2` is the `latest` DSP release, DSP will backport bugs/security fixes to `v1.1` as `PATCH` (z) releases.

Expand All @@ -59,6 +60,7 @@ Let `x.y-1.a` be the highest version release that is one `MINOR` version behind
**Example**:
If the latest release that is the highest version is `v1.2.0`\
Then:

```txt
x.y.z = v1.2.0
x.y-1.a = v1.1.0
Expand All @@ -83,10 +85,10 @@ Then the commit `08eb98d` needs to trickle to `vx.y.z` and `vx.y-1.a` as `PATCH`
* Using [release-tools] generate a params.env and submit a new pr to `vx.y.x` and `vx.y-1.x` branches
4. Cut `vx.y.z+1` and `vx.y-1.a+1` in DSP and DSPO

**Downstream Specifics**
#### Downstream Specifics

Downstream maintainers of DSP should:
* forward any manifest changes to their odh-manifests downstream

* ensure `odh-stable` branches in DSP/DSPO are upto date with bug/security fixes for the appropriate DSPO/DSP versions,
and forward any changes from `odh-stable` to their downstream DSPO/DSP repos

Expand Down
Loading