kitlauncher: pin kit to a kai-embedded version so kai code stays current#19
Open
jschatz1 wants to merge 1 commit into
Open
kitlauncher: pin kit to a kai-embedded version so kai code stays current#19jschatz1 wants to merge 1 commit into
kai code stays current#19jschatz1 wants to merge 1 commit into
Conversation
kai code resolved kit once and then ran the cached copy forever with no
version check, so users froze on whatever kit they first downloaded.
Add an opt-in pin: Launcher.ExpectedVersion (wired from PinnedKitVersion).
When set, kai code downloads the version-qualified asset
(kit-{os}-{arch}-{ver}.gz), records it in a kit.version sidecar, and
re-installs whenever the managed copy drifts — so it always runs the
pinned build. Empty (the default) preserves the exact rolling-latest
behavior, so this ships dormant until the /dl proxy serves versioned
assets and the constant is bumped.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
kai coderesolveskitonce (managed~/.kai/bin/kit, else PATH) and then execs that cached copy forever, with no version check.install()only runs when kit is absent. So after the firstkai code, a user is frozen on whatever kit they first downloaded — there is no "always latest" path today.Fix (Option A — pin kit to the kai release)
Make kit a versioned companion pinned to kai:
Launcher.ExpectedVersion, wired from a package constPinnedKitVersion.kai code:kit-{os}-{arch}-{ver}.gz,kit.versionsidecar,ErrKitStale→ atomic overwrite). A managed kit with no sidecar (oldinstall.sh) reads as stale → upgrades once.Why pinning over a per-launch "latest" check: kit always matches the kai you're running (compatibility guaranteed), no network on the hot path (only re-downloads right after a
kai update), works offline, and "latest kit" follows "latest kai" — which users already get viakai update/the installer.Ships dormant — safe to merge/release now
PinnedKitVersiondefaults to"", so behavior is unchanged. A non-empty pin would request an asset the/dlproxy can't serve yet (→404), so it stays empty until the backend is ready.Activation (separate, do together)
/dlproxy (kailab-control): serveapp.kaicontext.com/dl/kit-{os}-{arch}-{version}.gzby mapping{version}→ that tag's kai-tui release asset. Today it proxies only the unversioned rolling-latest.v*tag).PinnedKitVersion(ideally in lockstep with each kai release).Tests
7 new tests (versioned asset name, sidecar match/stale/missing, unpinned-ignores-version, pinned install writes sidecar + requests versioned asset,
Runre-installs on stale). Full existing suite still green.