Cut release branches first, land cherry-picks, release from branch #20
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The previous release process had complex branch logic that tried to determine where to push version bumps after releases. This created unnecessary complexity and made the release process harder to reason about. The new process is straightforward: each minor version (e.g., 0.1.x) gets one long-lived release branch that contains all RCs and patch releases for that series. Release branches are created on the first RC, not the final release. Changes: - Release branches (release-X.Y.x) now hold all releases for a minor version - Removed rc- temporary branches; RCs are tags on release branches - Removed determine_base_branch logic and complex ancestry checking - Auto-bump main via PR after final releases (patch + 1 + .dev0) - Removed unused inference_provider and API key parameters - Added version format validation - Fixed bug where client dependency used wrong variable in version bumps The workflow is now: cut RC from release branch → test/cherry-pick fixes → cut another RC → promote RC to final → main gets bumped automatically.
ashwinb
requested review from
ehhuang,
hardikjshah,
leseb,
raghotham,
reluctantfuturist and
slekkala1
Extracts release functions into tests/lib/release-functions.sh for unit testing. Adds unit tests covering version parsing, git operations, and version bump logic. Adds integration tests that simulate the full RC cutting workflow with synthetic repositories, verifying version bumps, branch creation, and commit history across multiple RCs. All 14 tests passing (13 unit + 1 integration suite).
ashwinb
changed the title
All repositories now live under the llamastack organization, not meta-llama.
ashwinb
commented
Oct 31, 2025
| @@ -0,0 +1,286 @@ | |||
| #!/usr/bin/env bash | |||
There was a problem hiding this comment.
look at this test and see if this is good or not
ashwinb
added a commit
to llamastack/llama-stack
that referenced
this pull request
Oct 31, 2025
Standardize CI workflows to use `release-X.Y.x` branch pattern instead of multiple numeric variants. That's the pattern we are settling on. See llamastack/llama-stack-ops#20 for reference.
|
Looks like it worked: https://github.com/llamastack/llama-stack-ops/actions/runs/18963105974 
|
raghotham
approved these changes
Oct 31, 2025
|
CI on the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes the release process to cut a release branch first (e.g.,
release-0.1.x), land cherry-picks onto it out-of-band, and always release from that branch. No more cutting fromorigin/mainor creating temporaryrc-$VERSIONbranches.New workflow:
When cutting the first RC for a minor version (e.g.,
0.1.0rc1), a release branch is created from main. All subsequent RCs and patch releases for that series work from the same long-lived branch. Cherry-picks land on the release branch between RCs. Final releases promote an RC tag by bumping version strings and pushing back to the release branch.After each final release, main is auto-bumped to the next dev version via PR (e.g.,
0.1.0→0.1.1.dev0).Changes:
determine_base_branch()complexity (70 lines)See
RELEASE_PROCESS.mdfor the complete workflow.