Frb Publish Release

FRB Publish Release

Use this skill when preparing, publishing, or babysitting a flutter_rust_bridge release.

Workflow

1. Preflight

• Work from the repository root on the intended release branch, normally fresh master. If the checkout is detached but already points at the intended release commit, switch or create a local release branch from that commit before running mutating release commands; do not treat detached HEAD itself as a release blocker.

• Check git status --short --branch and do not start publishing from a dirty tree.

• Check submodules before publishing:

  git submodule update --init --recursive
  git submodule status --recursive

  Stop if any submodule path remains uninitialized. A release built without initialized submodules can publish incomplete package contents. The release script performs the same submodule-status guard before publishing.

• Treat master as a moving branch. Before each irreversible release phase, fetch origin master, confirm the current release branch or detached checkout still points at the intended latest origin/master commit, and re-run git status --short --branch to confirm there are no unexpected local changes.

• Confirm the target version in CHANGELOG.md, root Cargo.toml, and frb_dart/pubspec.yaml.

• Compute the release versions the same way ./frb_internal release does: the top CHANGELOG.md version is the new version and the next release section is the old version.

• Verify both old and new versions are legal before running any mutating release command. The only allowed shapes are stable SemVer MAJOR.MINOR.PATCH such as 2.0.0, or beta SemVer MAJOR.MINOR.PATCH-beta.N such as 2.0.0-beta.1. Use exactly ^\d+\.\d+\.\d+(-beta\.\d+)?$.

• Reject versions with any other prerelease label, build metadata, missing numeric components, leading v, or loose text. Stop if either old or new version fails this check.

• Confirm the new version is different from the old version.

• Run the publish container credential preflight before starting irreversible publish steps:

  .claude/skills/frb-dev-env/frb_dev_env.py docker-run-rm --with-publish-credentials -- true

  Stop if the preflight fails. It checks GitHub CLI auth, Cargo credentials, and Dart pub credentials inside the same temporary credential layout used by release publishing.

• Confirm normal CI is green for the release commit before publishing. This is the default hard gate.

  A narrow exception is allowed only when all of these are true:

  • A recent earlier commit on the same release branch has fully green normal CI.
  • Every commit between that green commit and the intended release commit is unrelated to the publishable packages, version sources, generated release artifacts, and frb_internal release logic.
  • The mechanical gate script below exits successfully and its output is recorded in the release notes or journal.
  • The agent explicitly states that it is using the exception before publishing.

  Run the mechanical gate from the repository root:

  uv run --script .claude/skills/frb-publish-release/release_ci_gate.py \
    --base-green-ref <LAST_GREEN_SHA> \
    --release-ref HEAD

  Stop and wait for normal CI if the script reports any BLOCK path. The script is intentionally conservative: release-surface paths such as Cargo.toml, frb_dart/pubspec.yaml, frb_codegen/**, frb_macros/**, frb_rust/**, frb_utils/**, frb_example/**, tools/frb_internal/**, pubspec.yaml, melos.yaml, and lockfiles are not in the allowlist. Release metadata and its generated copies are allowed: CHANGELOG.md, frb_dart/CHANGELOG.md, frb_hooks/CHANGELOG.md, .all-contributors-custom.yaml, .all-contributorsrc, README.md, frb_dart/README.md, and website/**. These files are reviewed directly before publishing and do not affect package execution. Other frb_dart/** and frb_hooks/** paths remain blocked. This exception is for release metadata, docs, agent tooling, devcontainer, selected CI configuration, and other explicitly non-release paths only.

2. Reconcile Contributors

• Before writing the release changelog, use frb-add-contributor to identify contributors from the target release range who may need all-contributors credit or whose human-written custom description does not cover every release-range PR.
• Follow frb-add-contributor exactly. In particular, after determining which contributors may need to be added or have their custom descriptions extended, stop for human confirmation before editing contributor files, posting GitHub comments, triggering all-contributors, opening PRs, or merging contributor PRs.
• Do not continue to changelog preparation until contributor reconciliation is complete, or confirmed unnecessary because all contributors are credited and their custom descriptions cover every third-party PR in the release range.

3. Write Changelog

• Use frb-write-changelog and follow it exactly. It is the single source of truth for beta and stable changelog content, grouping, ordering, attribution, review, verification, and generated package changelog copies. Do not duplicate those rules here.
• Do not publish until the human-review gate required by frb-write-changelog is satisfied.
• The top CHANGELOG.md version is the source used by frb_internal release.
• If changelog or version files changed, commit that release preparation before publishing.
• Land contributor and changelog preparation commits on origin/master before publishing. Do not leave release preparation only on a side branch.