llm-cli-gateway 1.13.0 → 1.13.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +36 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,42 @@
|
|
|
2
2
|
|
|
3
3
|
All notable changes to the llm-cli-gateway project.
|
|
4
4
|
|
|
5
|
+
## [1.13.1] - 2026-05-27 — Installer Windows build fix (no code changes)
|
|
6
|
+
|
|
7
|
+
Patch release. **No changes to the gateway, MCP tools, or any provider
|
|
8
|
+
wiring.** npm + PyPI 1.13.1 packages are functionally identical to 1.13.0.
|
|
9
|
+
|
|
10
|
+
### Fixed
|
|
11
|
+
|
|
12
|
+
- `installer/build-release.sh` registered a function-scoped EXIT trap
|
|
13
|
+
that referenced a `local` variable (`staging`). When something inside
|
|
14
|
+
the function failed, `set -e` + `set -u` made the trap die with
|
|
15
|
+
`staging: unbound variable` AFTER the function had already returned
|
|
16
|
+
and its locals had gone out of scope — masking the real failure.
|
|
17
|
+
- This first surfaced on the v1.13.0 release-installer.yml Windows job
|
|
18
|
+
when GitHub started redirecting `windows-latest` to the new
|
|
19
|
+
`windows-2025-vs2026` image (rollout completes 2026-06-15). Linux
|
|
20
|
+
and both macOS targets still built clean.
|
|
21
|
+
- The fix lifts the staging path to a script-level `RVWR_STAGING_DIR`
|
|
22
|
+
variable, registers a single idempotent `cleanup_staging` helper
|
|
23
|
+
with `|| true` so the EXIT trap can't fail itself under `set -e`,
|
|
24
|
+
and defensively cleans up between iterations of the
|
|
25
|
+
`for target in TARGETS` loop.
|
|
26
|
+
- Smoke-tested locally on linux/amd64 (`npm ci` + `cp -R` + `tar` ran
|
|
27
|
+
clean; bundle produced; staging dir cleaned up). Once this reaches
|
|
28
|
+
the new tag, release-installer.yml either succeeds (the trap bug
|
|
29
|
+
WAS the whole problem) or fails with a clearer message we can
|
|
30
|
+
chase as a follow-up patch.
|
|
31
|
+
|
|
32
|
+
### Why a patch release for an installer-only fix
|
|
33
|
+
|
|
34
|
+
The `release-installer.yml` workflow checks out the tag it builds for
|
|
35
|
+
(`needs.resolve-tag.outputs.tag`) and re-running it against the
|
|
36
|
+
existing `v1.13.0` tag would pick up the broken script. A new tag is
|
|
37
|
+
the simplest way to get the fix onto CI without force-pushing
|
|
38
|
+
`v1.13.0`. npm + PyPI 1.13.1 are republished as a side-effect; this
|
|
39
|
+
matches the precedent of `v1.6.1` (docs-only follow-up to 1.6.0).
|
|
40
|
+
|
|
5
41
|
## [1.13.0] - 2026-05-27 — Phase 4 slice θ (Grok HIGH parity)
|
|
6
42
|
|
|
7
43
|
Ships the eighth Phase 4 slice: five HIGH-impact Grok CLI flags are now
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "llm-cli-gateway",
|
|
3
|
-
"version": "1.13.
|
|
3
|
+
"version": "1.13.1",
|
|
4
4
|
"mcpName": "io.github.verivus-oss/llm-cli-gateway",
|
|
5
5
|
"description": "MCP server providing unified access to Claude Code, Codex, Gemini, Grok, and Mistral Vibe CLIs with session management, retry logic, async job orchestration, durable job results, and cross-LLM validation.",
|
|
6
6
|
"license": "MIT",
|