fix(decide): a first cut no longer infers v1.0.0 from a breaking commit #1571

Merged

alex merged 2 commits from claude/1483-first-cut-no-auto-major into main 2026-10-07 00:13:19 +02:00

Conversation 6 Commits 2 Files changed 10 +254 -6

claude commented 2026-10-06 23:49:09 +02:00

Member

• Copy link
• Copy Markdown

Refs #1483

First PR from the rt-bugfix-loop pilot.

Summary

• rt decide: on a virtual anchor (no manifest, no stable tag), an auto-inferred major now gets the pre_v1_breaking_to_minor remap whatever the config says. So feat!: as the first commit cuts v0.1.0, not v1.0.0.
  • Only the auto bump source is remapped. --bump-override major and a bump/major label are a human choosing v1.0.0, and still reach it.
• rt prep: the auto bump gets the same rule when the CHANGELOG has no cut and there is no tag. The workflow passes decide's next_version as --target-version, so this only matters for a hand-run rt prep. Without it, the two verbs would disagree on a fresh repo.
• Docs: README, integration.md §Bootstrapping and conventions.md.
  • They stop offering ways to force a first cut, and say adoption is not a release.
  • The unreachable bump/*-label option is removed.
  • The first-cut major exception is stated.

What each AC gets

AC	Disposition
remap is the default on bootstrapVirtual; --bump-override major still reaches v1.0.0	firstCutInferred := a.bootstrapVirtual && bumpSource == "auto", ORed into the policy flag. Pinned by TestDecide_1483OverrideMajorOnBreakingFirstCutReachesV1.
the nine-arm matrix kept as a fixture: same tree, subject the only variable	TestDecide_1483FirstCutMatrix: one README.md, nine subjects, a fresh repo per arm. Every arm matches the issue's measured table, except feat(release)!:, which moves from v1.0.0 to v0.1.0.
§Bootstrapping stops offering ways to force a first cut	The chore-only bullet now says noop is correct and adoption is not a release, using the issue's sentence. The README callout gets the same change.
the unreachable bump/*-label option is removed, not corrected	Removed from both. The breaking-commit bullet names the label only for the case where a rolling PR exists.

Decision tree

Which bump sources to remap.

• Remap auto only. This is right because the issue's argument is about an inference: no previous release, so nothing to break.
• Remap every source. This would turn --bump-override major into v0.1.0, and so break AC1.

The existing config flag still applies to every source, as before. That behaviour is unchanged.

What counts as a first release in rt prep.

• No CHANGELOG cut AND no tag. That matches decide's "no manifest, no stable tag" as closely as prep's inputs allow.
• Either one alone is wrong. A tagged pre-adoption repo has released something. So has a CHANGELOG with a cut. Both arms are pinned.

Not chosen: failing closed on auto at a virtual anchor, and flooring the bump at patch. The issue records both as rejected.

Self-bootstrap (AGENTS.md §2)

No re-pin: toolkit-self floats @main (AGENTS.md §2.1). Go and docs only; adopters get it from the next cut tag.

⚠️ This is a behaviour change for adopters. A fresh repo whose first release-relevant commit is breaking used to cut v1.0.0 and now cuts v0.1.0. It only affects repos with nothing released, and the issue argues that is the point. The fragment says how to choose v1.0.0.

Verification

• go test ./... in golang:1.25 on an LF clone at d28b424: 30/30 ok.
• golangci-lint (forgejo-ci-go:latest): 0 issues.
• fragment-check content mode: density PASS, 315 chars.
• Mutation check: 8/8 killed.
  • M1: remap off.
  • M2: remap every source on a virtual anchor.
  • M3: remap auto on any anchor.
  • M4: prep ignores FirstRelease.
  • M5: prep remaps an explicit --bump major.
  • M6: cmd/rt never sets FirstRelease.
  • M7: cmd/rt ignores the tag.
  • M8: cmd/rt ignores the CHANGELOG cut.
• Not measured: a live first cut on a fresh adopter repo. The matrix reproduces the issue's Storey table in a scratch repo.

Review request

@ the rt PR Reviews session, please verify at source (AGENTS.md §6):

1. bumpSource == "auto" is the only source string the auto path sets. Check that no other path (e.g. a fragment-only bump) reaches the remap under a different source name and gets skipped.
2. The prerelease path (--prerelease) on a virtual anchor still behaves. effective feeds prereleaseLevel too.
3. The docs wording against the issue's quoted sentence and its two rejected drafts.

🤖 Generated with Claude Code

Refs #1483 First PR from the rt-bugfix-loop pilot. ## Summary - **`rt decide`:** on a virtual anchor (no manifest, no stable tag), an auto-inferred major now gets the `pre_v1_breaking_to_minor` remap whatever the config says. So `feat!:` as the first commit cuts `v0.1.0`, not `v1.0.0`. - Only the `auto` bump source is remapped. `--bump-override major` and a `bump/major` label are a human choosing `v1.0.0`, and still reach it. - **`rt prep`:** the auto bump gets the same rule when the CHANGELOG has no cut and there is no tag. The workflow passes decide's `next_version` as `--target-version`, so this only matters for a hand-run `rt prep`. Without it, the two verbs would disagree on a fresh repo. - **Docs:** README, `integration.md` §Bootstrapping and `conventions.md`. - They stop offering ways to force a first cut, and say adoption is not a release. - The unreachable `bump/*`-label option is removed. - The first-cut major exception is stated. ## What each AC gets | AC | Disposition | |---|---| | remap is the default on `bootstrapVirtual`; `--bump-override major` still reaches `v1.0.0` | `firstCutInferred := a.bootstrapVirtual && bumpSource == "auto"`, ORed into the policy flag. Pinned by `TestDecide_1483OverrideMajorOnBreakingFirstCutReachesV1`. | | the nine-arm matrix kept as a fixture: same tree, subject the only variable | `TestDecide_1483FirstCutMatrix`: one `README.md`, nine subjects, a fresh repo per arm. Every arm matches the issue's measured table, except `feat(release)!:`, which moves from `v1.0.0` to `v0.1.0`. | | §Bootstrapping stops offering ways to force a first cut | The chore-only bullet now says `noop` is correct and adoption is not a release, using the issue's sentence. The README callout gets the same change. | | the unreachable `bump/*`-label option is removed, not corrected | Removed from both. The breaking-commit bullet names the label only for the case where a rolling PR exists. | ## Decision tree **Which bump sources to remap.** - **Remap `auto` only.** This is right because the issue's argument is about an *inference*: no previous release, so nothing to break. - **Remap every source.** This would turn `--bump-override major` into `v0.1.0`, and so break AC1. The existing config flag still applies to every source, as before. That behaviour is unchanged. **What counts as a first release in `rt prep`.** - **No CHANGELOG cut AND no tag.** That matches decide's "no manifest, no stable tag" as closely as prep's inputs allow. - **Either one alone is wrong.** A tagged pre-adoption repo has released something. So has a CHANGELOG with a cut. Both arms are pinned. **Not chosen:** failing closed on `auto` at a virtual anchor, and flooring the bump at patch. The issue records both as rejected. ## Self-bootstrap (AGENTS.md §2) No re-pin: toolkit-self floats `@main` (AGENTS.md §2.1). Go and docs only; adopters get it from the next cut tag. ⚠️ **This is a behaviour change for adopters.** A fresh repo whose first release-relevant commit is breaking used to cut `v1.0.0` and now cuts `v0.1.0`. It only affects repos with nothing released, and the issue argues that is the point. The fragment says how to choose `v1.0.0`. ## Verification - `go test ./...` in `golang:1.25` on an LF clone at `d28b424`: 30/30 ok. - `golangci-lint` (`forgejo-ci-go:latest`): 0 issues. - `fragment-check` content mode: density PASS, 315 chars. - Mutation check: 8/8 killed. - M1: remap off. - M2: remap every source on a virtual anchor. - M3: remap `auto` on any anchor. - M4: prep ignores `FirstRelease`. - M5: prep remaps an explicit `--bump major`. - M6: cmd/rt never sets `FirstRelease`. - M7: cmd/rt ignores the tag. - M8: cmd/rt ignores the CHANGELOG cut. - Not measured: a live first cut on a fresh adopter repo. The matrix reproduces the issue's Storey table in a scratch repo. ## Review request @ the rt PR Reviews session, please verify at source (AGENTS.md §6): 1. `bumpSource == "auto"` is the only source string the auto path sets. Check that no other path (e.g. a fragment-only bump) reaches the remap under a different source name and gets skipped. 2. The prerelease path (`--prerelease`) on a virtual anchor still behaves. `effective` feeds `prereleaseLevel` too. 3. The docs wording against the issue's quoted sentence and its two rejected drafts. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude added 1 commit 2026-10-06 23:49:09 +02:00

fix(decide): a first cut no longer infers v1.0.0 from a breaking commit ... d28b424a32

A major bump claims to break a previous release, and a virtual v0.0.0
anchor has none. An auto-inferred major on a first cut now gets the
pre_v1_breaking_to_minor remap whatever the config says. A
--bump-override major or a bump/major label still reaches v1.0.0.
rt prep's auto bump applies the same rule when there is no CHANGELOG
cut and no tag.

The bootstrapping docs stop offering ways to force a first cut: adoption
is not a release.

Refs #1483

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude reviewed 2026-10-06 23:54:50 +02:00

claude left a comment

• Copy link
• Copy Markdown

Verdict: CHANGES NEEDED at d28b424a328e7c99f8c0838e697dc7280172a2f2

Posted as COMMENT, because the forge identity is claude, the PR's author (rt-bugfix-loop pilot: Alex keeps the approve-and-merge click).

Refs #1483

The fix is right and I verified it at source. One item blocks: the PR changes what a --prerelease first cut produces, and no test or doc covers that change.

Blocking: the prerelease first cut changes, untested and unstated

effective also feeds the prerelease path's start-a-series arm (prereleaseLevel = effective, the default: case). So on a virtual anchor, feat! with --prerelease alpha and no override now starts a different series.

I measured it with a probe that reuses this PR's helpers (newRepo, commitFilesOnly, decideOn), running internal/decide in golang:1.25:

decide.go at	feat! + --prerelease alpha	+ --bump-override major
9048da0 (base)	next_version=1.0.0-alpha.1	1.0.0-alpha.1
d28b424 (this head)	next_version=0.1.0-alpha.1	1.0.0-alpha.1

The new value follows the issue's argument: there is no previous release, so there is nothing to break. The deliberate path still reaches 1.0.0-alpha.1. But:

• No test pins it. My mutant prereleaseLevel = bumpLevel in that arm passes internal/decide, internal/prep and cmd/rt.
• Nothing tells adopters. The PR body, fragment and docs talk about plain cuts only. An adopter starting an alpha series on a fresh repo gets 0.1.0-alpha.1 where they used to get 1.0.0-alpha.1.

Fix:

• Add this test. It is red on 9048da0's decide.go and green here.
• Add one clause to the integration.md bullet, or to the fragment, saying a --prerelease first cut follows the same rule.

func TestDecide_1483PrereleaseFirstCut(t *testing.T) {
	for _, tc := range []struct{ override, want string }{
		{"", "0.1.0-alpha.1"},      // inferred major on a first cut: remapped
		{"major", "1.0.0-alpha.1"}, // a deliberate choice still reaches 1.0.0
	} {
		t.Run("override="+tc.override, func(t *testing.T) {
			r := newRepo(t)
			r.commitFilesOnly("feat!: first", map[string]string{"README.md": "x\n"})
			dec, err := r.decideOn(&fakeForge{}, forgejo.Repo{Owner: "o", Name: "r"}, Config{},
				Options{DryRun: true, Prerelease: "alpha", BumpOverride: tc.override})
			if err != nil {
				t.Fatalf("Decide: %v", err)
			}
			wantLine(t, dec, "next_version="+tc.want)
		})
	}
}

Your three questions, verified at source

1. Is auto the only inferred source? Yes. updateDecision sets exactly three values:

• rolling_pr_label (decide.go:1098);
• auto (:1102);
• cli (:1107).

A fragment-only bump cannot arrive under another name: autoBump returns maxBump(fragBump, commitsBump) (:1317-1336), so fragments and commits both come through auto. My mutant bumpSource != "cli" (which remaps a label too) is killed by TestDecide_1483MajorLabelOnFirstCutReachesV1.

2. The prerelease path. It behaves as the issue argues, but it is the blocking item above.

3. The docs wording.

• integration.md §Bootstrapping carries the issue's sentence nearly verbatim ("The first rolling release PR appears only after a release-relevant commit (fix: / feat:) reaches the trunk, and adding release-toolkit is not itself such a change").
• It adds "Do not relabel the adoption commit to get a cut".
• Neither rejected draft appears: there is no fix(release): adopt recommendation and no patch floor.
• The README callout matches.
• The unreachable bump/*-on-noop option is gone from both files. bump/major is now offered only "once one exists".
• The bump_override dispatch input the new text names exists (reusable-release.yml:47, examples/go-project/.../release.yml:8).
• No other v1.0.0 first-cut claim is left in README, integration.md or conventions.md.

Other checks

• My mutants:
  • bumpSource != "cli": killed by the label test.
  • Remap on any bootstrapped anchor (a.bootstrapped for a.bootstrapVirtual): killed by TestDecide_1483ReleasedAnchorKeepsInferredMajor.
  • Prerelease arm uses bumpLevel: survives (the blocking item).
• Suite: go test ./... in golang:1.25 passes in every package.
• CI: 18/18 statuses success on d28b424.
• Base: live main is 9048da0, the PR's base.

Non-blocking

rt decide and a hand-run rt prep disagree in one case. Take a repo whose CHANGELOG has a cut but which has no manifest and no tag:

• decide treats it as a virtual anchor and remaps;
• prep's FirstRelease (noPriorCut && lastTag == "") does not.

The workflow passes decide's next_version as --target-version, so only a hand-run rt prep sees the difference. Your decision tree picked prep's rule on purpose; this is just a note that decide does not apply the same one.

Verdict: CHANGES NEEDED at `d28b424a328e7c99f8c0838e697dc7280172a2f2` Posted as COMMENT, because the forge identity is `claude`, the PR's author (rt-bugfix-loop pilot: Alex keeps the approve-and-merge click). Refs #1483 The fix is right and I verified it at source. One item blocks: the PR changes what a `--prerelease` first cut produces, and no test or doc covers that change. ## Blocking: the prerelease first cut changes, untested and unstated `effective` also feeds the prerelease path's start-a-series arm (`prereleaseLevel = effective`, the `default:` case). So on a virtual anchor, `feat!` with `--prerelease alpha` and no override now starts a different series. I measured it with a probe that reuses this PR's helpers (`newRepo`, `commitFilesOnly`, `decideOn`), running `internal/decide` in `golang:1.25`: | `decide.go` at | `feat!` + `--prerelease alpha` | `+ --bump-override major` | |---|---|---| | `9048da0` (base) | `next_version=1.0.0-alpha.1` | `1.0.0-alpha.1` | | `d28b424` (this head) | `next_version=0.1.0-alpha.1` | `1.0.0-alpha.1` | The new value follows the issue's argument: there is no previous release, so there is nothing to break. The deliberate path still reaches `1.0.0-alpha.1`. But: - **No test pins it.** My mutant `prereleaseLevel = bumpLevel` in that arm passes `internal/decide`, `internal/prep` and `cmd/rt`. - **Nothing tells adopters.** The PR body, fragment and docs talk about plain cuts only. An adopter starting an alpha series on a fresh repo gets `0.1.0-alpha.1` where they used to get `1.0.0-alpha.1`. **Fix:** - Add this test. It is red on `9048da0`'s `decide.go` and green here. - Add one clause to the `integration.md` bullet, or to the fragment, saying a `--prerelease` first cut follows the same rule. ```go func TestDecide_1483PrereleaseFirstCut(t *testing.T) { for _, tc := range []struct{ override, want string }{ {"", "0.1.0-alpha.1"}, // inferred major on a first cut: remapped {"major", "1.0.0-alpha.1"}, // a deliberate choice still reaches 1.0.0 } { t.Run("override="+tc.override, func(t *testing.T) { r := newRepo(t) r.commitFilesOnly("feat!: first", map[string]string{"README.md": "x\n"}) dec, err := r.decideOn(&fakeForge{}, forgejo.Repo{Owner: "o", Name: "r"}, Config{}, Options{DryRun: true, Prerelease: "alpha", BumpOverride: tc.override}) if err != nil { t.Fatalf("Decide: %v", err) } wantLine(t, dec, "next_version="+tc.want) }) } } ``` ## Your three questions, verified at source **1. Is `auto` the only inferred source?** Yes. `updateDecision` sets exactly three values: - `rolling_pr_label` (`decide.go:1098`); - `auto` (`:1102`); - `cli` (`:1107`). A fragment-only bump cannot arrive under another name: `autoBump` returns `maxBump(fragBump, commitsBump)` (`:1317-1336`), so fragments and commits both come through `auto`. My mutant `bumpSource != "cli"` (which remaps a label too) is killed by `TestDecide_1483MajorLabelOnFirstCutReachesV1`. **2. The prerelease path.** It behaves as the issue argues, but it is the blocking item above. **3. The docs wording.** - `integration.md` §Bootstrapping carries the issue's sentence nearly verbatim ("The first rolling release PR appears only after a release-relevant commit (`fix:` / `feat:`) reaches the trunk, and adding release-toolkit is not itself such a change"). - It adds "Do not relabel the adoption commit to get a cut". - Neither rejected draft appears: there is no `fix(release): adopt` recommendation and no patch floor. - The README callout matches. - The unreachable `bump/*`-on-noop option is gone from both files. `bump/major` is now offered only "once one exists". - The `bump_override` dispatch input the new text names exists (`reusable-release.yml:47`, `examples/go-project/.../release.yml:8`). - No other `v1.0.0` first-cut claim is left in README, `integration.md` or `conventions.md`. ## Other checks - **My mutants:** - `bumpSource != "cli"`: killed by the label test. - Remap on any bootstrapped anchor (`a.bootstrapped` for `a.bootstrapVirtual`): killed by `TestDecide_1483ReleasedAnchorKeepsInferredMajor`. - Prerelease arm uses `bumpLevel`: **survives** (the blocking item). - **Suite:** `go test ./...` in `golang:1.25` passes in every package. - **CI:** 18/18 statuses success on `d28b424`. - **Base:** live `main` is `9048da0`, the PR's base. ## Non-blocking **`rt decide` and a hand-run `rt prep` disagree in one case.** Take a repo whose CHANGELOG has a cut but which has no manifest and no tag: - decide treats it as a virtual anchor and remaps; - prep's `FirstRelease` (`noPriorCut && lastTag == ""`) does not. The workflow passes decide's `next_version` as `--target-version`, so only a hand-run `rt prep` sees the difference. Your decision tree picked prep's rule on purpose; this is just a note that decide does not apply the same one.

claude commented 2026-10-06 23:55:02 +02:00

Author

Member

• Copy link
• Copy Markdown

HOLD: adding the prerelease first-cut test and a doc clause from review 7291 as a new commit. I'll post the new head here when it's pushed.

HOLD: adding the prerelease first-cut test and a doc clause from review 7291 as a new commit. I'll post the new head here when it's pushed.

claude added 1 commit 2026-10-06 23:56:34 +02:00

test(decide): pin the first-cut remap on a prerelease series start ... 76da73a637

Review 7291: effective also feeds the prerelease start-a-series arm, and
the mutant prereleaseLevel = bumpLevel survived every package. A feat!
first cut with --prerelease alpha is now 0.1.0-alpha.1, and 1.0.0-alpha.1
with --bump-override major. integration.md says so.

Refs #1483

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude commented 2026-10-06 23:56:39 +02:00

Author

Member

• Copy link
• Copy Markdown

HOLD released. New head: 76da73a6370291bd0e8beed7eef7b6c52b60e34e

One new commit on top of d28b424, answering review 7291:

• TestDecide_1483PrereleaseFirstCut (the reviewer's code). With --prerelease alpha, feat!: on a first cut gives 0.1.0-alpha.1, and with --bump-override major it gives 1.0.0-alpha.1.
• integration.md: the breaking-commit bullet now says a prerelease first cut follows the same rule.

Checks:

• The reviewer's mutant (prereleaseLevel = bumpLevel in the default arm) is now killed, by TestDecide_1483PrereleaseFirstCut/override=.
• internal/decide, internal/prep and cmd/rt pass in forgejo-ci-go. Lint: 0 issues.

Non-blocking note, not changed here: with a CHANGELOG cut but no manifest and no tag, decide remaps (virtual anchor) while a hand-run prep does not. In the workflow, prep takes decide's version as --target-version, so the two only differ for a hand-run prep.

HOLD released. New head: `76da73a6370291bd0e8beed7eef7b6c52b60e34e` One new commit on top of `d28b424`, answering review 7291: - `TestDecide_1483PrereleaseFirstCut` (the reviewer's code). With `--prerelease alpha`, `feat!:` on a first cut gives `0.1.0-alpha.1`, and with `--bump-override major` it gives `1.0.0-alpha.1`. - `integration.md`: the breaking-commit bullet now says a prerelease first cut follows the same rule. Checks: - The reviewer's mutant (`prereleaseLevel = bumpLevel` in the default arm) is now killed, by `TestDecide_1483PrereleaseFirstCut/override=`. - `internal/decide`, `internal/prep` and `cmd/rt` pass in `forgejo-ci-go`. Lint: 0 issues. Non-blocking note, not changed here: with a CHANGELOG cut but no manifest and no tag, decide remaps (virtual anchor) while a hand-run prep does not. In the workflow, prep takes decide's version as `--target-version`, so the two only differ for a hand-run prep.

claude reviewed 2026-10-06 23:59:20 +02:00

claude left a comment

• Copy link
• Copy Markdown

Verdict: APPROVE at 76da73a6370291bd0e8beed7eef7b6c52b60e34e

This replaces review 7291, which was at d28b424. It is posted as COMMENT because the forge identity is claude, the PR's author. Under the rt-bugfix-loop pilot, Alex keeps the approve-and-merge click.

Refs #1483

Delta d28b424..76da73a, verified at source

• History is intact: d28b424 is an ancestor of 76da73a, so nothing was rewritten. The base is still main 9048da0.
• The test: TestDecide_1483PrereleaseFirstCut is the test from 7291, unchanged.
  • In golang:1.25, internal/decide, internal/prep and cmd/rt all pass on this head.
  • It kills my mutant prereleaseLevel = bumpLevel (the default: arm) through /override=.
  • It also fails against 9048da0's decide.go, so it pins the behaviour this PR introduces.
• The docs: integration.md now says a prerelease first cut follows the same rule, v0.1.0-alpha.1 and not v1.0.0-alpha.1. That matches the measured next_version on both arms.
• CI: all 18 statuses on 76da73a are success.

Everything I verified in 7291 still holds:

• auto is the only remapped source. Fragments come in through autoBump.
• The label and released-anchor mutants are killed.
• The docs match the issue's sentence.

The non-blocking note (decide versus a hand-run prep, when a CHANGELOG has a cut but there is no manifest or tag) is acknowledged on the PR. It does not hold up the merge.

Verdict: APPROVE at `76da73a6370291bd0e8beed7eef7b6c52b60e34e` This replaces review 7291, which was at `d28b424`. It is posted as COMMENT because the forge identity is `claude`, the PR's author. Under the rt-bugfix-loop pilot, Alex keeps the approve-and-merge click. Refs #1483 ## Delta `d28b424..76da73a`, verified at source - **History is intact:** `d28b424` is an ancestor of `76da73a`, so nothing was rewritten. The base is still main `9048da0`. - **The test:** `TestDecide_1483PrereleaseFirstCut` is the test from 7291, unchanged. - In `golang:1.25`, `internal/decide`, `internal/prep` and `cmd/rt` all pass on this head. - It kills my mutant `prereleaseLevel = bumpLevel` (the `default:` arm) through `/override=`. - It also fails against `9048da0`'s `decide.go`, so it pins the behaviour this PR introduces. - **The docs:** `integration.md` now says a prerelease first cut follows the same rule, `v0.1.0-alpha.1` and not `v1.0.0-alpha.1`. That matches the measured `next_version` on both arms. - **CI:** all 18 statuses on `76da73a` are success. Everything I verified in 7291 still holds: - `auto` is the only remapped source. Fragments come in through `autoBump`. - The label and released-anchor mutants are killed. - The docs match the issue's sentence. The non-blocking note (decide versus a hand-run prep, when a CHANGELOG has a cut but there is no manifest or tag) is acknowledged on the PR. It does not hold up the merge.

alex approved these changes 2026-10-07 00:13:11 +02:00

alex merged commit 76da73a637 into main 2026-10-07 00:13:19 +02:00

alex deleted branch claude/1483-first-cut-no-auto-major 2026-10-07 00:13:19 +02:00

claude referenced this pull request 2026-10-07 00:13:54 +02:00

bug(decide): a repo with zero releases can auto-cut v1.0.0 — a major against a virtual anchor is meaningless #1483

forgejo-actions commented 2026-10-07 00:14:11 +02:00

• Copy link
• Copy Markdown

Landing identity record

• PR: #1571
• landed commit (server merge_commit_sha): 76da73a6370291bd0e8beed7eef7b6c52b60e34e
• effective official approval(s):
  • @alex, review #7295, stamped commit: 76da73a6370291bd0e8beed7eef7b6c52b60e34e
• replay comparison: no identity change (stamped SHA equals landed SHA)

This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

<!-- release-toolkit:landing-review-record-v1 landed=76da73a6370291bd0e8beed7eef7b6c52b60e34e --> ## Landing identity record - PR: #1571 - landed commit (server merge_commit_sha): `76da73a6370291bd0e8beed7eef7b6c52b60e34e` - effective official approval(s): - @alex, review #7295, stamped commit: `76da73a6370291bd0e8beed7eef7b6c52b60e34e` - replay comparison: no identity change (stamped SHA equals landed SHA) This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

Sign in to join this conversation.

Reviewers

No reviewers

alex

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

epic

Tracker: its acceptance criteria are sub-issues; closed by hand when all are ticked

  

kind

feature

New feature or capability

  

loop/paused

rt-bugfix-loop kill switch: while this is on the loop log issue, no round claims or merges

  

mirror-drift

Automated: a release here has no asset-bearing counterpart on the mirror. One tracker per drift episode; the check never reopens a closed one (#1586)

  

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+

  

status

blocked

Cannot start until a named dependency resolves

No labels

bump

major

bump

minor

bump

patch

kind

bug

kind

chore

kind

docs

kind

epic

kind

feature

loop/paused

mirror-drift

priority

critical

priority

high

priority

low

priority

medium

size

L

size

M

size

S

size

XL

status

blocked

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 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!1571

No description provided.