docs(rfc): define stable release policy - #2695
Conversation
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
krishicks
left a comment
krishicks
left a comment
There was a problem hiding this comment.
I left some questions inline. I'm wondering who the different release artifacts are for; who should use a release candidate, and why? What expectations should they have with such a release?
I think it may be implied what each release (dev, rc, release) might be for, but it would probably be good to make it explicit: who should use them, what expectations can they have about them.
There are also two candidates: the RC candidate (unqualified main?) and then the RC itself, since every commit becomes a dev release but only some get promoted to RCs following qualification on main (I guess? since the dev release is a branch off of commit to main in the diagram?).
I feel like breaking API change review needs to happen earlier in the cycle, because it also informs the version. If I get to 0.1.2-rc.2 and there's a breaking change, that should then become 0.1.3-rc.0, or something (what happens to 0.1.2 final, then?). It's not clear to me what should happen if a breaking API change is detected when in the process of qualifying a release candidate which intends to make that breaking API change and is marked as such. Possibly the same with security review; it feels like security qualification should be an rc prerequisite (and this relates to expectations a user should have about an rc.)
|
|
||
| OpenShell builds a release candidate nightly for the next expected stable | ||
| release when `main` has changed and normal CI passes. After `0.1.1`, candidates | ||
| are numbered `0.1.2-rc.1`, `0.1.2-rc.2`, and so on. A release candidate is promoted to a stable release tag as part of the weekly release pipeline once the candidate has passed qualification. |
There was a problem hiding this comment.
What happens if the most recent candidate doesn't pass qualification?
There was a problem hiding this comment.
If an RC doesn't pass release qualification then it's not an eligible stable build and can't be promoted.
There was a problem hiding this comment.
But then what happens with the release? Is there no stable release for that week? Is a previous release candidate promoted instead?
There was a problem hiding this comment.
If the latest RC isn't passing qualification then I think it's probably best to fail the automated stable release and have someone intervene and get the RC passing. This is most similar to how things work today, which seems to be working alright.
| the patch version by default, for example `0.1.1` followed by `0.1.2`. A release | ||
| may instead increment the minor version when it introduces notable new features | ||
| or documented breaking changes. A stable tag is published only when there are | ||
| changes and every blocking qualification suite passes. |
There was a problem hiding this comment.
How will we be relating versions of the different release artifacts? Do they share the same version? For example, if something in the Rust code changes that necessitates a patch version bump, do the SDKs share that version and get bumped even with no changes?
There was a problem hiding this comment.
All our published artifacts share the same version and are released at the same time.
| Breaking API change review runs once per candidate. It compares the candidate's | ||
| stable protobuf and public SDK interfaces with the latest stable baseline and | ||
| any additional baseline required by the N-1 maintenance promise. The review: |
There was a problem hiding this comment.
@krishicks pulling out a question you left in your review
I feel like breaking API change review needs to happen earlier in the cycle
We could run breaking API change review on branch checks as well. Example scenarios when a PR contains a breaking API change
| Latest stable | Next RC | Branch disposition | Resolution |
|---|---|---|---|
| 0.2.0 | 0.3.0-rc.1 | Pass | Continue release qualification |
| 0.2.0 | 0.2.0-rc.2 | Fail | Increment the minor version and set next release to 0.3.0-rc.1 |
2 participants
Summary
Propose RFC 0014, defining OpenShell's alpha exit criteria and the stable release policy for per-commit development builds, nightly-generated release candidates, and weekly stable releases.
Related Issue
Supersedes #2148. RFC 0014 consolidates that earlier support-matrix and API-compatibility proposal into the broader release-stability design.
Changes
Testing
mise run pre-commitpassesChecklist