From 6ea707c1419ba27ba83445141c1b9accc2367829 Mon Sep 17 00:00:00 2001 From: Lukas Wuttke Date: Mon, 31 Aug 2026 17:22:05 +0200 Subject: [PATCH] chore(release): bump to 0.10.19 so the staging hop can tag again (backend#2790) The 2026-08-31 staging settle refused cli: rc NOT tagged - v0.10.18 already exists and the delta DOES touch published files (bump VERSION on develop before the next release) v0.10.18 is tagged and the staging->develop delta touches `internal/*` and `scripts/install.ps1`, both declared publish paths. Re-tagging would make one tag name two different trees. PATCH, measured. Two commits, both `fix`: fix(ingest): report the physical destination table, not the requested name fix(install): a VERIFIED signature no longer kills the Windows install (#611) No feat, nothing breaking, so 0.10.18 -> 0.10.19. FIFTH INSTANCE OF THIS TODAY, and the count is the point. design-system-v2 hit it twice (v0.1.0, v0.1.1) and this is cli's turn; a fourth apparent case on design-system-v2 today turned out to be a STALE MIRROR rather than a missing bump, which is its own argument for automating the distinction instead of eyeballing it. Every release needs the bump the NEXT release is refused without, and doing it by hand means a refused settle is how we find out. `.github#372` builds `post-release-bump.yml` for exactly this. This repo needs its caller; that is the third checkbox on backend#2790. Part of tracebloc/backend#2790 --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index 3971e7e..86c1984 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.10.18 +0.10.19