Fluid Framework Client Release

Release workflow for the client release group. Supports two modes: interactive (default) and autonomous.

Environment Detection

Check the CI environment variable at the start of every session:

• CI=true: Running in a GitHub Actions workflow. Use only origin (no upstream). Use CI-safe commands (see CI-safe alternatives). Never prompt for input. Log blockers and phase completions to workflow output for human review.
• CI unset or false: Running locally. Use upstream/origin detection as described in Key Context.

Mode Selection

At the start of every release session, ask the user:

Would you like to run in interactive or autonomous mode?

In CI (CI=true), always use autonomous mode — do not prompt.

Interactive Mode (default)

Run commands autonomously but pause before creating PRs, pushing branches, or triggering builds. Ask for version confirmation at key points. This is the current behavior.

Autonomous Mode

Run the entire selected phase end-to-end without pausing. Auto-detect the release state from the schedule and repo (see below). If the user provides version info upfront, skip the version questions entirely.

Requirements:

• Version info upfront: The user must provide all version numbers before starting (current release version and/or next version, depending on phase). Do not prompt for versions mid-flow. If the user doesn't provide versions, detect them from the schedule and repo state (see below).
• No confirmation pauses: Create PRs, push branches, and run flub release without asking. Include clear commit messages and PR descriptions.
• Phase-scoped execution: Each phase runs to completion, then reports what the user needs to do next (e.g., "queue the ADO build" or "wait for npm feeds, then re-invoke for type test updates").
• Fallback to issues: If any step fails (permission errors, CI-safe command failures, git push rejected, or any other error that prevents progress), stop and open a GitHub issue in microsoft/FluidFramework describing what was completed, what failed, and what remains. Use the title format Release <VERSION>: <brief description> and label it with release-blocking. Include the exact commands remaining so a human can finish using the skill in interactive mode.

Auto-detecting release state (autonomous mode and CI)

Auto-detect the release state from the schedule and repo. Read the release schedule and run the detection steps below. In interactive mode, this detection also runs when the user gives a generic request like "do the release" without specifying a version or phase.

Step 1: Identify the most recent release.

# Get the latest client release tag
git tag -l 'client_v2.*' --sort=-version:refname | head -1

Step 2: Identify the next scheduled release.

Compare today's date against the schedule. The next release is the earliest scheduled entry whose proposed date is >= today and whose version is greater than the most recently released version. Also check if a release is overdue (proposed date < today but no tag exists).

Step 3: Check if a release is in progress.

# Check for release-prep branches for the next version
git ls-remote --heads upstream 'release-prep/<NEXT_VERSION>/*'
# Check for the release branch
git ls-remote --heads upstream 'release/client/<NEXT_MAJOR>.<NEXT_MINOR>'
# Check for a release tag
git tag -l 'client_v<NEXT_VERSION>'
# Check for open PRs
gh pr list --repo microsoft/FluidFramework --search "release-prep/<NEXT_VERSION>" --state all

Step 4: Determine the phase and act.

…