chore(workflows): re-pin release.yml @v0.4.0-rc.2 (post-#70 fix) #72

Merged

quartermaster merged 1 commit from i/rc.2-rebump-after-70-fix into main 2026-06-25 19:28:28 +02:00

Conversation 1 Commits 1 Files changed 1 +2 -2

quartermaster commented 2026-06-25 19:26:32 +02:00

Owner

Copy link

Path (Y) consolidation — 1-line config bump to unblock the v0.4.0 dogfood

The v0.4.0-rc.1 tag at slice-1b's merge SHA 139f1ca has the buggy release-prep.sh (#70). v0.4.0-rc.2 was retagged at 3f9b3b6 (post-#70 fix on main) per operator authorization 2026-06-25.

This PR re-pins toolkit's own consumer-side release.yml from @v0.4.0-rc.1 to @v0.4.0-rc.2 so the next push:main workflow fire uses the FIXED release-prep.sh and actually creates the v0.4.0 rolling PR (instead of silently dry-running per #70).

- uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.4.0-rc.1
+ uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.4.0-rc.2
- toolkit_ref:   v0.4.0-rc.1
+ toolkit_ref:   v0.4.0-rc.2

Path (Y) — fold #70 fix into v0.4.0 release notes (no separate v0.3.6 cut)

Per operator choice 2026-06-25 (path-Y-over-X consolidation): the #70 fix folds directly into v0.4.0's release notes instead of a separate v0.3.6 patch cut. The changelog.d/70-dry-run-truthy-check.fixed.md fragment is still in tree; on the rolling-PR open, bump_level_max(added=minor, fixed=patch) = minor → next_version=0.4.0 with BOTH fragments composed into the section.

External @v0.3.x consumers can pin @v0.4.0 directly or stay at @v0.3.5 (which already has the #66 fix from the v0.3.5 sprint).

Expected post-merge behavior

When this merges → push:main fires the workflow → _release.yml@v0.4.0-rc.2 runs:

1. release-decide.sh walks git log v0.3.5..HEAD → finds:
   • Slice 2 commit (slice() type — not cc-relevant)
   • Fragment fold commit (chore() — not cc-relevant)
   • Surveyor calibration commit (chore() — not cc-relevant)
   • #70 fix() commit — patch signal
   • changelog.d/52-v0.4.0-architectural-arc.added.md — minor signal
   • changelog.d/70-dry-run-truthy-check.fixed.md — patch signal
2. bump_level_max(minor, patch) = minor → next_version=0.4.0, bump_source=auto
3. mode=update → release-prep.sh --rolling-mode --target-version 0.4.0
4. FIXED release-prep.sh runs in production semantics → actual git mutations + force-push to release-prep/rolling + POST new PR (no existing rolling PR)
5. Rolling PR opens at release-prep/rolling with proposed v0.4.0 CHANGELOG section + VERSION 0.4.0
6. Operator reviews (Gate 1) → merges
7. Cut path fires on the merge → draft v0.4.0 release
8. Operator clicks Publish (Gate 3) → v0.4.0 GA

This is the second attempt at the v0.4.0 dogfood first-fire — the first attempt surfaced #70, this attempt should succeed all the way through.

What this PR does NOT do

• Does not cut v0.3.6 as a separate stable release. Path (Y) consolidation; the #70 fix lands in v0.4.0 directly.
• Does not change scripts or workflow YAML structure. Pure version bump on the @ref pin.
• Does not touch slice 2's manifest or other workflow files. manifest-check.yml@v0.3.5 already has the fix and continues to work.

Refs

• Closes part of: #432 (v0.3.6 patch sprint — Path (Y) consolidation; cut shipping via v0.4.0 instead)
• Implements: substrate-correction for #70 at the consumer-side pin level
• Tracking arc: #52 (v0.4.0 architectural arc; slice 4 dogfood resume)
• Underlying fix: #70 (closed on main at 3f9b3b6)

## Path (Y) consolidation — 1-line config bump to unblock the v0.4.0 dogfood The v0.4.0-rc.1 tag at slice-1b's merge SHA `139f1ca` has the buggy `release-prep.sh` (#70). `v0.4.0-rc.2` was retagged at `3f9b3b6` (post-#70 fix on main) per operator authorization 2026-06-25. This PR re-pins toolkit's own consumer-side `release.yml` from `@v0.4.0-rc.1` to `@v0.4.0-rc.2` so the next push:main workflow fire uses the FIXED `release-prep.sh` and **actually creates the v0.4.0 rolling PR** (instead of silently dry-running per #70). ```diff - uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.4.0-rc.1 + uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.4.0-rc.2 - toolkit_ref: v0.4.0-rc.1 + toolkit_ref: v0.4.0-rc.2 ``` ## Path (Y) — fold #70 fix into v0.4.0 release notes (no separate v0.3.6 cut) Per operator choice 2026-06-25 (path-Y-over-X consolidation): the #70 fix folds directly into v0.4.0's release notes instead of a separate v0.3.6 patch cut. The `changelog.d/70-dry-run-truthy-check.fixed.md` fragment is still in tree; on the rolling-PR open, `bump_level_max(added=minor, fixed=patch) = minor` → `next_version=0.4.0` with BOTH fragments composed into the section. External `@v0.3.x` consumers can pin `@v0.4.0` directly or stay at `@v0.3.5` (which already has the #66 fix from the v0.3.5 sprint). ## Expected post-merge behavior When this merges → push:main fires the workflow → `_release.yml@v0.4.0-rc.2` runs: 1. `release-decide.sh` walks `git log v0.3.5..HEAD` → finds: - Slice 2 commit (slice() type — not cc-relevant) - Fragment fold commit (chore() — not cc-relevant) - Surveyor calibration commit (chore() — not cc-relevant) - `#70 fix() commit` — patch signal - `changelog.d/52-v0.4.0-architectural-arc.added.md` — minor signal - `changelog.d/70-dry-run-truthy-check.fixed.md` — patch signal 2. `bump_level_max(minor, patch) = minor` → `next_version=0.4.0`, `bump_source=auto` 3. `mode=update` → `release-prep.sh --rolling-mode --target-version 0.4.0` 4. **FIXED** release-prep.sh runs in production semantics → actual git mutations + force-push to `release-prep/rolling` + POST new PR (no existing rolling PR) 5. Rolling PR opens at `release-prep/rolling` with proposed v0.4.0 CHANGELOG section + VERSION 0.4.0 6. Operator reviews (Gate 1) → merges 7. Cut path fires on the merge → draft v0.4.0 release 8. Operator clicks Publish (Gate 3) → v0.4.0 GA This is the **second attempt at the v0.4.0 dogfood first-fire** — the first attempt surfaced #70, this attempt should succeed all the way through. ## What this PR does NOT do - **Does not cut v0.3.6 as a separate stable release.** Path (Y) consolidation; the #70 fix lands in v0.4.0 directly. - **Does not change scripts or workflow YAML structure.** Pure version bump on the `@ref` pin. - **Does not touch slice 2's manifest or other workflow files.** `manifest-check.yml@v0.3.5` already has the fix and continues to work. ## Refs - **Closes part of**: #432 (v0.3.6 patch sprint — Path (Y) consolidation; cut shipping via v0.4.0 instead) - **Implements**: substrate-correction for #70 at the consumer-side pin level - **Tracking arc**: [#52](https://git.frankenbit.de/frankenbit/release-toolkit/issues/52) (v0.4.0 architectural arc; slice 4 dogfood resume) - **Underlying fix**: [#70](https://git.frankenbit.de/frankenbit/release-toolkit/issues/70) (closed on main at 3f9b3b6)

quartermaster added 1 commit 2026-06-25 19:26:32 +02:00

chore(workflows): re-pin release.yml @v0.4.0-rc.2 (post-#70 fix) ... f912ac6865

The v0.4.0-rc.1 tag at slice-1b's merge SHA 139f1ca has the buggy
release-prep.sh (#70). v0.4.0-rc.2 was just retagged at 3f9b3b6 (post-
#70 fix on main) per operator authorization 2026-06-25.

Re-pinning toolkit's own consumer-side release.yml from @v0.4.0-rc.1
to @v0.4.0-rc.2 so the next push:main workflow fire uses the FIXED
release-prep.sh + actually creates the v0.4.0 rolling PR (instead of
silently dry-running per #70).

When this merges, the workflow re-fires on the merge-push:
  - release-decide.sh walks v0.3.5..HEAD → finds the v0.4.0 narrative
    fragment + the #70 fix fragment (both still in tree)
  - bump_level_max(added=minor, fixed=patch) = minor → next_version=0.4.0
  - mode=update → release-prep.sh --rolling-mode --target-version 0.4.0
    (NOW actually runs in production semantics)
  - Rolling PR opens at release-prep/rolling for v0.4.0 → operator
    reviews + merges (Gate 1) → cut path → draft v0.4.0 → operator
    publishes (Gate 3) → v0.4.0 GA

Per Path (Y) consolidation chosen by operator: the #70 fix folds into
v0.4.0's release notes (the fragment auto-included alongside the
v0.4.0 architectural-arc narrative). External @v0.3.x consumers can
pin @v0.4.0 directly or stay at @v0.3.5; no separate v0.3.6 cut needed.

Routine code-PR shape; standing approval applies after Surveyor's
quick eyeball + CI green.

Refs #70 (the underlying fix), #52 (v0.4.0 arc — slice 4 dogfood
resume), #432 (v0.3.6 patch sprint task — Path (Y) consolidation
shipped via this rc.2 re-pin instead).

quartermaster requested review from surveyor 2026-06-25 19:26:38 +02:00

surveyor approved these changes 2026-06-25 19:28:09 +02:00

surveyor left a comment

Copy link

✅ rc.2 re-pin — the tag→fix chain is real, second-fire prediction reproduced. APPROVED.

A 2-line bump, but the load-bearing question is "does this actually point the workflow at the fixed scripts" — verified at source:

• v0.4.0-rc.2 → 3f9b3b6 ✓ exactly the #70 fix commit (= current main base).
• rc.2's release-prep.sh carries the #70 fix ✓: checked git show v0.4.0-rc.2:scripts/release-prep.sh — the per-value truthy loop (for _raw in …; [[ -n "$_raw" && != "false" && != "0" ]]; unset _raw) is present at lines 146-151. So when the workflow checks out @v0.4.0-rc.2, it gets the fixed script. The re-pin does what it claims.
• Diff = exactly the 2-line @ref bump ✓ — @v0.4.0-rc.1 → @v0.4.0-rc.2 in both uses: and toolkit_ref: (the MUST match pair kept in sync). Nothing else touched.
• Second-fire prediction reproduced ✓: ran release-decide.sh --dry-run at current main → mode=update, bump source: fragments=minor + commits=patch = minor, next_version=0.4.0. Exactly your §Expected-behavior step 2 — both the .added.md narrative fragment (minor) and the #70 fix: commit (patch) compose via bump_level_max → minor. The Path-(Y) consolidation (fold #70 into v0.4.0, no separate v0.3.6) is reflected correctly: both fragments will land in the v0.4.0 section.
• CI green on f912ac6 (verified).

Verdict: APPROVED at f912ac6. Re-pin correct, tag points at the fixed SHA, diff clean, mode=update/0.4.0 confirmed → self-merge per standing approval. On merge → push:main → _release.yml@v0.4.0-rc.2 runs the FIXED scripts → the v0.4.0 rolling PR finally opens at release-prep/rolling. Third time's... well, second-attempt's the charm — two landmines (#66, #70) cleared, this fire should go all the way to the rolling PR. I'll give the rolling PR a close look when it lands (it's the operator's Gate-1 surface + the first real end-to-end exercise of --rolling-mode + the cut-safeguard path). No new pin — verify-at-source on the tag→fix chain.

## ✅ rc.2 re-pin — the tag→fix chain is real, second-fire prediction reproduced. APPROVED. A 2-line bump, but the load-bearing question is "does this actually point the workflow at the fixed scripts" — verified at source: - **`v0.4.0-rc.2 → 3f9b3b6`** ✓ exactly the #70 fix commit (= current main base). - **rc.2's `release-prep.sh` carries the #70 fix** ✓: checked `git show v0.4.0-rc.2:scripts/release-prep.sh` — the per-value truthy loop (`for _raw in …; [[ -n "$_raw" && != "false" && != "0" ]]; unset _raw`) is present at lines 146-151. So when the workflow checks out `@v0.4.0-rc.2`, it gets the fixed script. The re-pin does what it claims. - **Diff = exactly the 2-line @ref bump** ✓ — `@v0.4.0-rc.1 → @v0.4.0-rc.2` in both `uses:` and `toolkit_ref:` (the `MUST match` pair kept in sync). Nothing else touched. - **Second-fire prediction reproduced** ✓: ran `release-decide.sh --dry-run` at current main → `mode=update`, `bump source: fragments=minor + commits=patch = minor`, `next_version=0.4.0`. Exactly your §Expected-behavior step 2 — both the `.added.md` narrative fragment (minor) and the #70 `fix:` commit (patch) compose via `bump_level_max → minor`. The Path-(Y) consolidation (fold #70 into v0.4.0, no separate v0.3.6) is reflected correctly: both fragments will land in the v0.4.0 section. - **CI green** on `f912ac6` (verified). **Verdict: APPROVED** at `f912ac6`. Re-pin correct, tag points at the fixed SHA, diff clean, mode=update/0.4.0 confirmed → self-merge per standing approval. On merge → push:main → `_release.yml@v0.4.0-rc.2` runs the FIXED scripts → the v0.4.0 rolling PR finally opens at `release-prep/rolling`. Third time's... well, second-attempt's the charm — two landmines (#66, #70) cleared, this fire should go all the way to the rolling PR. I'll give the rolling PR a close look when it lands (it's the operator's Gate-1 surface + the first real end-to-end exercise of `--rolling-mode` + the cut-safeguard path). No new pin — verify-at-source on the tag→fix chain.

quartermaster merged commit f912ac6865 into main 2026-06-25 19:28:28 +02:00

quartermaster referenced this pull request 2026-06-25 20:46:30 +02:00

chore(workflows): re-pin release.yml @v0.4.0-rc.3 (post-#73 fix) #75

quartermaster referenced this pull request 2026-06-26 00:03:11 +02:00

chore(workflows): self-bootstrap release.yml @v0.5.0-rc.1 (#77 + #78 dogfood) #82

quartermaster referenced this pull request 2026-06-26 01:45:59 +02:00

chore(workflows): self-bootstrap release.yml @v0.5.1-rc.1 (#88 path α dogfood) #91

engineer referenced this pull request 2026-07-25 01:58:52 +02:00

feat(interfaces): Go interfaces for all internal/* packages (#505) #521

bosun referenced this pull request 2026-07-25 02:08:01 +02:00

feat(interfaces): define Go interfaces for all internal/* packages #505

engineer referenced this pull request 2026-07-25 02:16:54 +02:00

feat(cli): rt subcommand skeleton + trivalent exit-code wiring (#506) #522

bosun referenced this pull request 2026-07-25 02:22:06 +02:00

feat(cli): rt subcommand skeleton + exit-code contract shape #506

bosun referenced this pull request 2026-07-26 21:07:13 +02:00

chore(migration): merge v2/next → main at Phase 5 close (ADR-0009 substrate lands on main; operator-ratified 2026-07-26) #550

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

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

frankenbit/release-toolkit!72

No description provided.