Release: cut a `main` release (integration → main pin retarget + merge) #14

New issue

Open

opened 2026-06-14 13:18:44 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-06-14 13:18:44 +00:00

Owner

Tracking issue for the deliberate integration → main release cut. hero_company's implementation is complete on integration (the design arc and all phase sub-issues are closed); main is the coordinated, reproducible release line. This issue captures everything needed so the cut is turnkey when we choose to ship.

Not started now — by design. We stay integration-only until something actually consumes main (a tagged release, or a grid deploy). Cutting main earlier only creates a branch that lags integration and needs re-cuts, for no current benefit.

Feasibility (verified)

hero_company builds cleanly against hero_lib main today: cargo check --workspace is green with the direct hero_lib pins retargeted to hero_lib's current main tip f7dbc223, and the workspace versions match at 0.6.0. So the cut is currently unblocked.

Upstream / cross-repo preconditions

hero_lib — main must contain the hero_lib code hero_company uses. True today (f7dbc223). Re-verify before each cut: if new integration work starts using newer hero_lib APIs, hero_lib must promote them to its own main first. Prefer a fixed rev/tag over branch = "main" for reproducibility (today that is rev = "f7dbc223"; better still, a hero_lib release tag if one is cut).
hero_skills / lab — only needed on main if we also want the lab service-registry entry on main. It is not a build dependency of hero_company, so it is a separate, optional promotion.

Release procedure (per `docs/branching.md`)

Branch release/vX off integration.
Retarget the 6 direct hero_lib pins — hero_lifecycle, herolib_derive, herolib_openrpc, herolib_oschema_server, herolib_core, herolib_ai — from branch = "integration" to the chosen main rev/tag; re-lock Cargo.lock.
cargo check --workspace && cargo test --workspace + lab infocheck against the retargeted pins (suite green; service compliance clean).
Verify the branch-pin guard grep prints nothing — no integration/development pins remain.
Single commit with Cargo.toml + Cargo.lock together.
Open a PR release/vX → main; merge as a merge-commit; confirm the ci branch-pin guard passes on main.
Optional: tag the release; a grid deploy consumes the published main artifacts; front the app with the SSO door to light up the company/restricted tiers.

Housekeeping

docs/branching.md release checklist currently lists 5 deps to retarget; update it to the current 6 (it predates herolib_ai).

Definition of done

main builds, the full suite is green, and lab infocheck is clean against the main pins; ci is green on main; optionally the release is tagged.

Tracking issue for the deliberate `integration` → `main` release cut. hero_company's implementation is complete on `integration` (the design arc and all phase sub-issues are closed); `main` is the coordinated, reproducible release line. This issue captures everything needed so the cut is turnkey when we choose to ship. **Not started now — by design.** We stay integration-only until something actually consumes `main` (a tagged release, or a grid deploy). Cutting `main` earlier only creates a branch that lags `integration` and needs re-cuts, for no current benefit. ## Feasibility (verified) hero_company builds cleanly against `hero_lib` `main` today: `cargo check --workspace` is green with the direct `hero_lib` pins retargeted to `hero_lib`'s current main tip `f7dbc223`, and the workspace versions match at `0.6.0`. So the cut is currently unblocked. ## Upstream / cross-repo preconditions - **`hero_lib`** — `main` must contain the `hero_lib` code hero_company uses. True today (`f7dbc223`). Re-verify before each cut: if new integration work starts using newer `hero_lib` APIs, `hero_lib` must promote them to its own `main` first. Prefer a fixed `rev`/`tag` over `branch = "main"` for reproducibility (today that is `rev = "f7dbc223"`; better still, a `hero_lib` release tag if one is cut). - **`hero_skills` / lab** — only needed on `main` if we also want the lab service-registry entry on `main`. It is not a build dependency of hero_company, so it is a separate, optional promotion. ## Release procedure (per `docs/branching.md`) 1. Branch `release/vX` off `integration`. 2. Retarget the **6** direct `hero_lib` pins — `hero_lifecycle`, `herolib_derive`, `herolib_openrpc`, `herolib_oschema_server`, `herolib_core`, `herolib_ai` — from `branch = "integration"` to the chosen `main` `rev`/`tag`; re-lock `Cargo.lock`. 3. `cargo check --workspace && cargo test --workspace` + `lab infocheck` against the retargeted pins (suite green; service compliance clean). 4. Verify the branch-pin guard grep prints nothing — no `integration`/`development` pins remain. 5. Single commit with `Cargo.toml` + `Cargo.lock` together. 6. Open a PR `release/vX` → `main`; merge as a merge-commit; confirm the `ci` branch-pin guard passes on `main`. 7. Optional: tag the release; a grid deploy consumes the published `main` artifacts; front the app with the SSO door to light up the company/restricted tiers. ## Housekeeping - `docs/branching.md` release checklist currently lists 5 deps to retarget; update it to the current **6** (it predates `herolib_ai`). ## Definition of done `main` builds, the full suite is green, and `lab infocheck` is clean against the `main` pins; `ci` is green on `main`; optionally the release is tagged.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_company#14

No description provided.

Rows
Columns

Release: cut a main release (integration → main pin retarget + merge) #14