Release Branch Management

Manages the bundle release workflow: developers branch from release/*, PRs target release/* directly, and after publishing, changes sync back to x via rebase.

Context

OneKey ships periodic App Shell releases (tagged v{X.Y.Z} on the x branch). After each App Shell release, a release branch (release/v{X.Y.Z}) is created from the tag. Bundle release features are developed directly on this branch — PRs target release/*, not x. After bundle publishing, changes are synced back to x via rebase.

Release branch auto-detection: All subcommands use the shared detection logic below to determine the release branch. On a release/v* branch it's used directly; otherwise the latest release branch is discovered from the remote.

Release Branch Detection (Shared)

All subcommands MUST use this logic instead of reading .env.version directly. The reason: .env.version on x contains the next version (e.g., 6.2.0), while the release branch uses the current version (e.g., release/v6.1.0). Reading .env.version from x produces the wrong branch name.

current_branch=$(git branch --show-current)

if [[ "$current_branch" == release/v* ]]; then
  # Already on a release branch — use it directly
  RELEASE_BRANCH="$current_branch"
else
  # Not on a release branch — find the latest one from remote
  git fetch origin
  RELEASE_BRANCH=$(git branch -r \
    | grep 'origin/release/v' \
    | grep -v mock \
    | sed 's|origin/||' \
    | sort -V \
    | tail -1 \
    | tr -d ' ')
fi

if [[ -z "$RELEASE_BRANCH" ]]; then
  echo "No release branch found on origin."
  exit 1
fi

After detection, confirm with the user:

"Detected release branch: $RELEASE_BRANCH. Proceed? (y/n)"

If the user wants a different branch, let them specify it manually.

Quick Reference

Subcommand Routing

Parse the argument passed to this skill:

• checkout [branch-name] or 1 [branch-name] → Read and follow checkout.md
• prepare or 2 → Read and follow prepare.md
• pr or 3 → Read and follow pr.md
• diff-check or 4 → Read and follow diff-check.md
• audit or 5 → Read and follow audit.md
• publish or 6 → Read and follow publish.md
• sync or 7 → Read and follow sync.md
• No argument → Show this numbered quick reference and ask the user to reply with either the subcommand name or its number

Typical Release Flow

/1k-bundle-release checkout feat/my-fix   ← Branch from release/* to start work
  ... develop ...
/1k-bundle-release prepare                ← Set BUILD_NUMBER
/1k-bundle-release pr                     ← Create PR targeting release/*
  ... QA verifies, merge ...
/1k-bundle-release diff-check             ← Quick changeset review
/1k-bundle-release audit                  ← Full security audit (optional, recommended)
/1k-bundle-release publish                ← Record release in RELEASES.json (via PR)
/1k-bundle-release sync                   ← Rebase changes to x

These steps are designed to run in sequence, but each can also run independently.

Key Files

Related Skills

• /1k-dev-commands — Branch naming, commit conventions
• /commit — Create commits