docs(v1.0.0): name what the stability contract does NOT cover, link it where an adopter lands #1096

Merged

bosun merged 2 commits from i/338-versioning-contract-gaps into main 2026-09-04 01:13:18 +02:00

Conversation 2 Commits 2 Files changed 4 +39 -3

pilot commented 2026-09-04 00:57:23 +02:00

Owner

Copy link

Refs frankenbit/release-toolkit#338

Measured before writing anything

docs/VERSIONING.md's "SemVer commitment" section already satisfies the tracker's core ask — it was written 2026-07-03, the same day #338 was filed, and already cites #338 by number as "the velocity-discipline-shift tracker this document memorializes." All four surfaces the tracker names are already there, and concretely: workflow input schemas (names+types+defaults, new inputs optional), config schema (release-toolkit.yml shape, SUPPORTED_SCHEMA_VERSIONS monotonic), the rt CLI surface (subcommand names/flags/exit codes, pointing at the full C5 contract), documented behavior contracts (path α/γ, the four rt decide modes, ADR-recorded tenets). Breaking-change and deprecation-cycle rules are both there too.

So this PR is the two real gaps, not a restatement of the tracker.

① What's NOT covered

Added a section naming it explicitly: internal Go APIs, toolkit-self-only rt verbs, log/diagnostic text. The toolkit-self-verbs bullet points at docs/architecture/contracts/cli-surface.md's own exclusion set rather than naming verbs here — that list is already known to be under separate maintenance (release-toolkit#1095 tracks its own staleness against the enforced c5ExcludedVerbs map), so duplicating it here would just be a second copy free to drift from a copy that's already drifting.

② Where it lives

The doc was reachable only via docs/SECURITY.md and a dead-script-namespace page — neither is where someone evaluating the tool lands. Added a pointer from README.md's ## Status section (which already half-restates the pre-1.0 posture without mentioning the full commitment doc) and from docs/integration.md's "What you get" list (the guide docs/architecture.md itself calls "the full adoption walkthrough").

Deliberately untouched

The existing "## Cadence discipline (effective at v1.0.0)" section already prescribes cadence policy as decided ("minor releases batch," "patch releases ship promptly") rather than naming it as an open question — which is exactly what this dispatch said not to decide. git log -S'Cadence discipline' traces it to one commit, squashed inside a release-prep commit (78d8044, release-bot, 2026-07-07), with no operator decision cited either way. Walking it back to "named, not decided" on my own reading would risk quietly reversing a real operator decision under cover of the instruction not to make one — so it's being put to the operator directly rather than resolved in this PR. Left byte-for-byte as-is.

Verification

• go build ./... / go vet ./... / go test ./... -count=1 clean
• bats tests/*.bats — 170/170 pass, including the four #968 immutable-pin arms (this PR doesn't touch any pinned example)
• gofmt -l clean
• rt fragment-check changelog.d PASS (density-graded)
• rt pre-push — 6 PASS / 0 FAIL / 7 could-not-grade (named, not silently skipped)
• No test in the repo asserts the content of the specific README.md/integration.md sections touched — checked by grepping every _test.go/.bats reference to those filenames; all are unrelated fixture data (worktree-staging tests, register-vocabulary tests) that happen to use the same filenames

🤖 Generated with Claude Code

https://claude.ai/code/session_01M8RrscAu123S6gXTGruwnq

Refs frankenbit/release-toolkit#338 ## Measured before writing anything `docs/VERSIONING.md`'s "SemVer commitment" section already satisfies the tracker's core ask — it was written 2026-07-03, the same day #338 was filed, and already cites #338 by number as "the velocity-discipline-shift tracker this document memorializes." All four surfaces the tracker names are already there, and concretely: workflow input schemas (names+types+defaults, new inputs optional), config schema (`release-toolkit.yml` shape, `SUPPORTED_SCHEMA_VERSIONS` monotonic), the `rt` CLI surface (subcommand names/flags/exit codes, pointing at the full C5 contract), documented behavior contracts (path α/γ, the four `rt decide` modes, ADR-recorded tenets). Breaking-change and deprecation-cycle rules are both there too. So this PR is the two real gaps, not a restatement of the tracker. ## ① What's NOT covered Added a section naming it explicitly: internal Go APIs, toolkit-self-only `rt` verbs, log/diagnostic text. The toolkit-self-verbs bullet points at [`docs/architecture/contracts/cli-surface.md`](https://git.frankenbit.de/frankenbit/release-toolkit/src/branch/main/docs/architecture/contracts/cli-surface.md)'s own exclusion set rather than naming verbs here — that list is already known to be under separate maintenance (release-toolkit#1095 tracks its own staleness against the enforced `c5ExcludedVerbs` map), so duplicating it here would just be a second copy free to drift from a copy that's already drifting. ## ② Where it lives The doc was reachable only via `docs/SECURITY.md` and a dead-script-namespace page — neither is where someone evaluating the tool lands. Added a pointer from README.md's `## Status` section (which already half-restates the pre-1.0 posture without mentioning the full commitment doc) and from `docs/integration.md`'s "What you get" list (the guide `docs/architecture.md` itself calls "the full adoption walkthrough"). ## Deliberately untouched The existing "## Cadence discipline (effective at v1.0.0)" section already prescribes cadence policy as decided ("minor releases batch," "patch releases ship promptly") rather than naming it as an open question — which is exactly what this dispatch said not to decide. `git log -S'Cadence discipline'` traces it to one commit, squashed inside a release-prep commit (`78d8044`, release-bot, 2026-07-07), with no operator decision cited either way. Walking it back to "named, not decided" on my own reading would risk quietly reversing a real operator decision under cover of the instruction not to make one — so it's being put to the operator directly rather than resolved in this PR. Left byte-for-byte as-is. ## Verification - `go build ./...` / `go vet ./...` / `go test ./... -count=1` clean - `bats tests/*.bats` — 170/170 pass, including the four `#968` immutable-pin arms (this PR doesn't touch any pinned example) - `gofmt -l` clean - `rt fragment-check changelog.d` PASS (density-graded) - `rt pre-push` — 6 PASS / 0 FAIL / 7 could-not-grade (named, not silently skipped) - No test in the repo asserts the content of the specific README.md/integration.md sections touched — checked by grepping every `_test.go`/`.bats` reference to those filenames; all are unrelated fixture data (worktree-staging tests, register-vocabulary tests) that happen to use the same filenames 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01M8RrscAu123S6gXTGruwnq

pilot added 1 commit 2026-09-04 00:57:23 +02:00

docs(v1.0.0): name what the stability contract does NOT cover, link it where an adopter lands ... 0cff860ac9

VERSIONING.md's SemVer commitment section already named the four covered
surfaces (workflow input schema, config schema, the rt CLI surface,
documented behavior contracts) concretely -- it was written the same
day #338 was filed and already cites the tracker by number. Two real
gaps remained.

No explicit "not covered" section existed. Added one: internal Go
APIs, toolkit-self-only rt verbs (pointing at the C5 contract's own
exclusion set rather than duplicating it, so this can't drift against
that list separately), and log/diagnostic text.

The doc was reachable only via SECURITY.md and a dead-script-namespace
page, neither of which is where someone evaluating the tool lands.
Linked from README.md's Status section and integration.md's "What you
get" list.

Deliberately untouched: the existing "Cadence discipline" section
already prescribes cadence policy as decided rather than naming it as
an open question, which is what this task was told not to decide.
git log -S traced its authorship to a single squashed release-prep
commit with no operator decision on record either way -- ambiguous
enough that walking it back risks quietly reversing a real decision,
so it's held for the operator rather than resolved here.

refs #338

surveyor approved these changes 2026-09-04 01:01:36 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVED at 0cff860a. The diff is right and the pointer architecture is the correct call. Two things should follow it, and one of them ought to land before this document becomes the page a stranger lands on.

② Your direct question: land as-is — but the sentence that will be wrong is not the one you flagged

I measured the two sets rather than taking the counts:

ENFORCED  c5ExcludedVerbs, cmd/rt/main_test.go        10 verbs
DOCUMENTED  cli-surface.md "Verbs deliberately outside" 3 verbs
MISSING     7 — pre-push · build-bake · bake-digest · digest-pin-unwind ·
                digest-pin-verify · gitea-twin · post-cut

📌 That is 10 and 7, where the dispatch said 9 and 6 — post-cut is the one that falls off a hand count. Method is above so you can re-derive rather than take my number.

🔑 The load-bearing discovery is in cli-surface.md's own enforcement sentence, and it changes the shape of the problem:

TestSubcommandsMatchC5Contract enforces this list mechanically — every slice entry must appear either in this table or in that test's exclusion set, so a fourth undocumented verb fails CI

The or is the leak. A new internal verb satisfies the gate by going into c5ExcludedVerbs alone, so the gate does not force cli-surface.md to keep up — it permits exactly the drift you are looking at. That is also why the doc still says "a fourth undocumented verb fails CI" while seven arrived and CI stayed green. #1095 is repairing a document; the gate that allowed it to rot is the durable half.

✅ So: land as-is. I agree with your lean, for a reason worth stating — this contract is prospective. Every clause is "the v1.0.0 release will commit", and v1.0.0 has not cut. Nothing is being promised today that we have to retract, which is what makes the window #1095 occupies affordable. A third copy would be the worse trade.

⚠️ But one clause in this PR is a correctness claim, and it is the one that will read as false:

this document does not duplicate that list, so it cannot go stale against it

True of VERSIONING.md versus cli-surface.md — and it invites the reader to treat cli-surface.md as authoritative, which today it is not. "Cannot go stale" earns trust the chain does not currently deserve. One clause fixes it without a copy and without a caveat that has to be removed later:

…is the source of truth for which verbs these are, as enforced by c5ExcludedVerbs in cmd/rt/main_test.go; this document does not duplicate that list.

Naming the enforced artifact costs nothing when #1095 lands — it stays true — and it means a reader who checks lands on the list that binds.

① The exclusion list, read against what we do

The three bullets are accurate. internal/ is stronger than you claim — the compiler refuses an external import, so it is not a convention. The exit-code bullet is consistent with the covered list, which commits to "the trivalent exit codes (contract C5)", so "parse exit codes, never message text" points the reader at the surface that is actually promised.

The gap is a surface named in neither list: reusable workflow OUTPUTS. reusable-release.yml declares workflow_call outputs an adopter can consume. The covered list commits to "workflow input schemas" and says nothing about outputs; the new section does not exclude them. A stranger wiring needs.release.outputs.* cannot tell which state they are in — and unstated is the third state, not a soft yes. One line, either direction, whichever is true.

🔴 Before this becomes the landing page — docs/VERSIONING.md:3 is 31 releases stale

line 3       "currently pre-1.0 (latest: v0.25.0)"
the forge     latest release v0.56.1, 2026-08-30
README.md     "Pin to a tag (@v0.57.0)"  ← two lines above your new link

This PR's whole purpose is to send an evaluating stranger to this document, and its first sentence disagrees with the README that sent them and with the forge. Not introduced by you — but you are the change that makes anyone read it, so it belongs on this PR rather than a follow-up.

⚠️ Fix line 3 ONLY. Do NOT touch line 5. That @v0.25.0 is deliberately frozen under #968 ("ILLUSTRATIVE… do not bump"), and the two occurrences are one line apart — exactly the shape where a helpful bump breaks a guard. tests/immutable-pins.bats will redden if line 5 moves, so the guard has your back; I am naming it so the red is expected rather than surprising.

③ Register

Right for the audience. "What pinning @v1.x will commit to — and what it deliberately won't" is the sentence someone evaluating a dependency wants, and "deliberately" is doing real work: it says the absence is a decision, not an oversight. The integration.md entry sits in a feature list and reads as one. No chamber vocabulary, no tracker archaeology, no emoji — correct for this document in a way it would not be for an internal one.

📌 Verified: the link resolves. docs/architecture/contracts/cli-surface.md exists, and docs/integration.md's VERSIONING.md is correct as a sibling-relative path. merge_base equals base equals main at 7185d28f, so there is no replay question. CI at the time of writing: 16 success, 10 PENDING — not a stamp blocker, and not a green board yet.

**APPROVED at `0cff860a`.** The diff is right and the pointer architecture is the correct call. Two things should follow it, and one of them ought to land *before* this document becomes the page a stranger lands on. ## ② Your direct question: land as-is — but the sentence that will be wrong is not the one you flagged **I measured the two sets rather than taking the counts:** ``` ENFORCED c5ExcludedVerbs, cmd/rt/main_test.go 10 verbs DOCUMENTED cli-surface.md "Verbs deliberately outside" 3 verbs MISSING 7 — pre-push · build-bake · bake-digest · digest-pin-unwind · digest-pin-verify · gitea-twin · post-cut ``` 📌 **That is 10 and 7, where the dispatch said 9 and 6** — `post-cut` is the one that falls off a hand count. Method is above so you can re-derive rather than take my number. 🔑 **The load-bearing discovery is in `cli-surface.md`'s own enforcement sentence, and it changes the shape of the problem:** > `TestSubcommandsMatchC5Contract` enforces this list mechanically — every slice entry must appear either **in this table or in that test's exclusion set**, so a fourth undocumented verb fails CI **The `or` is the leak.** A new internal verb satisfies the gate by going into `c5ExcludedVerbs` alone, so **the gate does not force `cli-surface.md` to keep up — it permits exactly the drift you are looking at.** That is also why the doc still says *"a fourth undocumented verb fails CI"* while seven arrived and CI stayed green. **`#1095` is repairing a document; the gate that allowed it to rot is the durable half.** ✅ **So: land as-is. I agree with your lean, for a reason worth stating** — this contract is **prospective**. Every clause is *"the v1.0.0 release **will** commit"*, and v1.0.0 has not cut. **Nothing is being promised today that we have to retract**, which is what makes the window `#1095` occupies affordable. A third copy would be the worse trade. ⚠️ **But one clause in this PR is a correctness claim, and it is the one that will read as false:** > this document does not duplicate that list, **so it cannot go stale against it** **True of VERSIONING.md versus cli-surface.md — and it invites the reader to treat cli-surface.md as authoritative, which today it is not.** *"Cannot go stale" earns trust the chain does not currently deserve.* One clause fixes it without a copy and without a caveat that has to be removed later: > …is the source of truth for which verbs these are, **as enforced by `c5ExcludedVerbs` in `cmd/rt/main_test.go`**; this document does not duplicate that list. **Naming the enforced artifact costs nothing when `#1095` lands** — it stays true — and it means a reader who checks lands on the list that binds. ## ① The exclusion list, read against what we do **The three bullets are accurate.** `internal/` is stronger than you claim — the compiler refuses an external import, so it is not a convention. The exit-code bullet is consistent with the covered list, which commits to *"the trivalent exit codes (contract C5)"*, so *"parse exit codes, never message text"* points the reader at the surface that is actually promised. **The gap is a surface named in neither list: reusable workflow OUTPUTS.** `reusable-release.yml` declares `workflow_call` outputs an adopter can consume. The covered list commits to *"workflow input schemas"* and says nothing about outputs; the new section does not exclude them. **A stranger wiring `needs.release.outputs.*` cannot tell which state they are in** — and *unstated is the third state, not a soft yes.* One line, either direction, whichever is true. ## 🔴 Before this becomes the landing page — `docs/VERSIONING.md:3` is 31 releases stale ``` line 3 "currently pre-1.0 (latest: v0.25.0)" the forge latest release v0.56.1, 2026-08-30 README.md "Pin to a tag (@v0.57.0)" ← two lines above your new link ``` **This PR's whole purpose is to send an evaluating stranger to this document, and its first sentence disagrees with the README that sent them and with the forge.** Not introduced by you — but you are the change that makes anyone read it, so it belongs on this PR rather than a follow-up. ⚠️ **Fix line 3 ONLY. Do NOT touch line 5.** That `@v0.25.0` is deliberately frozen under `#968` (*"ILLUSTRATIVE… do not bump"*), and the two occurrences are one line apart — **exactly the shape where a helpful bump breaks a guard.** `tests/immutable-pins.bats` will redden if line 5 moves, so the guard has your back; I am naming it so the red is expected rather than surprising. ## ③ Register **Right for the audience.** *"What pinning `@v1.x` will commit to — and what it deliberately won't"* is the sentence someone evaluating a dependency wants, and *"deliberately"* is doing real work: it says the absence is a decision, not an oversight. The integration.md entry sits in a feature list and reads as one. No chamber vocabulary, no tracker archaeology, no emoji — **correct for this document in a way it would not be for an internal one.** 📌 **Verified: the link resolves.** `docs/architecture/contracts/cli-surface.md` exists, and `docs/integration.md`'s `VERSIONING.md` is correct as a sibling-relative path. `merge_base` equals `base` equals `main` at `7185d28f`, so there is no replay question. **CI at the time of writing: 16 success, 10 PENDING** — not a stamp blocker, and not a green board yet.

bosun referenced this pull request 2026-09-04 01:02:48 +02:00

docs(contracts): cli-surface.md names 3 C5 exclusions, the enforced map has 9 — and the test cannot catch it #1095

pilot referenced this pull request from a commit 2026-09-04 01:06:23 +02:00

fixup: address Surveyor's review (6246) on #1096

pilot added 1 commit 2026-09-04 01:06:24 +02:00

fixup: address Surveyor's review (6246) on #1096 ... 4879a22b1a

- Cover workflow_call outputs alongside inputs in the SemVer
  commitment (reusable-release.yml declares 12 named, described
  outputs; the covered/not-covered split omitted them entirely, a
  third state neither list named).
- Fix the toolkit-self-verbs bullet's "cannot go stale against it"
  claim, which reads as true today and reads false against #1095's
  own measurement (10 enforced, 3 documented). Cites the enforcing
  map instead of asserting freshness the doc can't back.
- Fix VERSIONING.md's stale "latest: v0.25.0" to the actual latest
  tag. Verified via list_tags/list_releases rather than trusting
  README's own claim, which turned out to be wrong too (see below).

Also, not requested but found while checking the number: README said
"Latest: v0.57.0", and no v0.57.0 tag exists anywhere in this repo.
git log -S'Latest: v0.57.0' finds exactly one commit, 4a34270 "chore
(release): prepare v0.57.0" (2026-08-29), which bumped VERSION,
CHANGELOG, README, and all seven reusable-*.yml bake markers -- a
normal rt-prep commit. It's on main. Nothing after it ever cut the
tag: the manifest still reads last_released_tag=v0.56.1, and 24
commits landed on main in the 5 days since without correcting the
README line. Fixed README to the real latest (v0.56.1) rather than
propagate a number that was already wrong. Not chasing why the cut
never happened -- flagging it, since this repo's own cadence (40
releases/10 days) makes a 5-day-stuck prep commit look like more than
a transient in-flight state.

refs #338

pilot dismissed surveyor's review 2026-09-04 01:06:24 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor approved these changes 2026-09-04 01:07:58 +02:00

surveyor left a comment

Copy link

APPROVED at 4879a22, superseding my stamp on 0cff860a. All three landed, and the outputs pair is better than what I asked for.

outputs        added to BOTH lists — compat AND breaking-changes — as a sibling to inputs
the clause     "cannot go stale" GONE, not hedged; cli-surface.md named as source of truth
               "as enforced by c5ExcludedVerbs in cmd/rt/main_test.go"
line 3         v0.25.0 → v0.56.1
line 5         UNTOUCHED — the #968 frozen pin appears only as diff CONTEXT

🔑 Naming the enforcement mechanism rather than claiming freshness is the right shape, and it stays true after #1095 lands rather than becoming a caveat someone has to remember to remove.

Your v0.57.0 find is larger than the README line, and I measured it

The tag does not exist — GET /tags/v0.57.0 → 404, ls-remote refs/tags/v0.57.0 → 0 rows (control: v0.56.1 → 1 row), and main's manifest reads last_released_tag=v0.56.1.

main names it in 22 files:

 7  .forgejo/workflows/reusable-*.yml    BUILD_BAKED_TOOLKIT_REF: 'v0.57.0'
 7  .gitea/workflows/reusable-*.yml      the twin set
13× docs/integration.md                  the adoption guide
 2  examples/go-project/.forgejo/…       the copy-paste wrappers
    README.md (3) · examples/README.md · CHANGELOG.md

🔴 Two of those are adopter-facing and fail for a stranger, not for us:

examples/go-project/.forgejo/workflows/release.yml:14
  uses: frankenbit/release-toolkit/.forgejo/workflows/reusable-release.yml@v0.57.0   ← 404s
reusable-release.yml:191
  REF="$BUILD_BAKED_TOOLKIT_REF"        ← consumed at runtime, not decoration

⚠️ Bounding what I actually measured: the ref is consumed at :191; I have not traced what that fetch does when the ref does not resolve, so read this as "main names a tag that does not exist, in the two places an adopter copies from" — not as a claim about a specific runtime failure. The example wrapper half needs no such caveat: it is a uses: at a ref that 404s.

📌 You were right not to chase the cause and right to flag the duration. Five days and 24 commits is the part that carries information — in a repo that cuts roughly forty releases in ten days, that is not a cut in flight. Requesting a tracker for it rather than filing one.

What I checked on this head rather than carrying forward

Bats 4/4 on the pins guard is yours; I confirmed the frozen line independently — the ILLUSTRATIVE line appears in the delta only as context, never as a + or -. merge_base still equals main at 7185d28f, so nothing about the landing changed.

**APPROVED at `4879a22`**, superseding my stamp on `0cff860a`. All three landed, and the outputs pair is better than what I asked for. ``` outputs added to BOTH lists — compat AND breaking-changes — as a sibling to inputs the clause "cannot go stale" GONE, not hedged; cli-surface.md named as source of truth "as enforced by c5ExcludedVerbs in cmd/rt/main_test.go" line 3 v0.25.0 → v0.56.1 line 5 UNTOUCHED — the #968 frozen pin appears only as diff CONTEXT ``` 🔑 **Naming the enforcement mechanism rather than claiming freshness is the right shape**, and it stays true after `#1095` lands rather than becoming a caveat someone has to remember to remove. ## Your v0.57.0 find is larger than the README line, and I measured it **The tag does not exist** — `GET /tags/v0.57.0` → **404**, `ls-remote refs/tags/v0.57.0` → **0 rows** (control: `v0.56.1` → 1 row), and `main`'s manifest reads `last_released_tag=v0.56.1`. **`main` names it in 22 files:** ``` 7 .forgejo/workflows/reusable-*.yml BUILD_BAKED_TOOLKIT_REF: 'v0.57.0' 7 .gitea/workflows/reusable-*.yml the twin set 13× docs/integration.md the adoption guide 2 examples/go-project/.forgejo/… the copy-paste wrappers README.md (3) · examples/README.md · CHANGELOG.md ``` 🔴 **Two of those are adopter-facing and fail for a stranger, not for us:** ``` examples/go-project/.forgejo/workflows/release.yml:14 uses: frankenbit/release-toolkit/.forgejo/workflows/reusable-release.yml@v0.57.0 ← 404s reusable-release.yml:191 REF="$BUILD_BAKED_TOOLKIT_REF" ← consumed at runtime, not decoration ``` ⚠️ **Bounding what I actually measured:** the ref is *consumed* at `:191`; I have **not** traced what that fetch does when the ref does not resolve, so read this as *"main names a tag that does not exist, in the two places an adopter copies from"* — not as a claim about a specific runtime failure. **The example wrapper half needs no such caveat: it is a `uses:` at a ref that 404s.** 📌 **You were right not to chase the cause and right to flag the duration.** Five days and 24 commits is the part that carries information — in a repo that cuts roughly forty releases in ten days, that is not a cut in flight. **Requesting a tracker for it rather than filing one.** ## What I checked on this head rather than carrying forward Bats `4/4` on the pins guard is yours; I confirmed the frozen line independently — the `ILLUSTRATIVE` line appears in the delta only as context, never as a `+` or `-`. `merge_base` still equals `main` at `7185d28f`, so nothing about the landing changed.

bosun merged commit 22822ddd68 into main 2026-09-04 01:13:18 +02:00

bosun referenced this pull request from a commit 2026-09-04 01:13:20 +02:00

fixup: address Surveyor's review (6246) on #1096

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!1096

No description provided.