chore(kirocrew): pin KiroCrew to stable 0.4.1rc1 - #109
Open
royosherove wants to merge 2 commits into
Open
Conversation
added 2 commits
September 2, 2026 07:08
The kirocrew pack pinned 0.3.0 as its default version. Upstream has since cut 0.4.1, which is the current Latest stable release on kirodotdev/KiroCrew, so new installs were landing several releases behind. Bump the pinned default in both places that carry it, and refresh the user-facing text that names the version: - packs/kirocrew/install.sh: pack_config_get fallback, the --kirocrew-version help default, and the stable-lane compatibility note. - packs/kirocrew/manifest.yaml: the param default and the channel/version mismatch example. The channel/version coupling documented in these strings is unchanged: both values still form cli/<channel>/<version>/cli-manifest.json, so an unmatched pair still 403s. Only the version they name moves. Validation: packs/kirocrew/test.sh 73/73 pass, bash -n clean, git diff --check clean, shellcheck -S warning reports only the two pre-existing SC2034 warnings already present on main.
Review caught that the previous commit's pin of "0.4.1" is not installable.
The pack passes --version straight to the upstream installer, which builds
cli/<channel>/<version>/cli-manifest.json and kirocrew-<version>-py3-none-any.whl
from it. Upstream tags the release v0.4.1 but publishes the CLI artifact as
0.4.1rc1, so the tag and the artifact version are not interchangeable.
Measured against the real CDN the installer uses:
stable/0.4.1 cli-manifest.json -> 403
stable/0.4.1rc1 cli-manifest.json -> 200
stable/0.4.1rc1 wheel -> 200
stable/0.3.0 cli-manifest.json -> 200 (old pin, control)
feed/stable/latest-cli.json independently reports version 0.4.1rc1 with
wheel_url .../cli/stable/0.4.1rc1/kirocrew-0.4.1rc1-py3-none-any.whl, and a
host already running the stable lane reports "kirocrew 0.4.1rc1".
Pinning "0.4.1" would therefore have 403'd every install -- the exact failure
mode this param's own documentation warns about.
Changes:
- Pin 0.4.1rc1 in the install.sh fallback and the manifest default.
- Rewrite the help text and manifest description to say this is the ARTIFACT
version rather than the GitHub tag, and to name feed/stable/latest-cli.json
as the way to confirm a pin before changing it. The prior wording ("cut on
the stable lane only") was also misleading: a v0.4.1-insider.1 prerelease
exists, and Insider carries a distinct version identifier.
- Add a "version pin consistency" test asserting manifest default == code
fallback == help default, so a future bump cannot silently leave one of the
three stale.
Validation: packs/kirocrew/test.sh 75/75 pass (73 before, +2 new). The new
assertion was negative-tested: drifting the manifest default to 9.9.9 in an
isolated copy fails with "pin disagrees: manifest='9.9.9' code='0.4.1rc1'
help='0.4.1rc1'". bash -n clean on both files, shellcheck -S warning clean on
test.sh, and install.sh's warning set is unchanged from origin/main (3 SC2034,
pre-existing).
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
packs/kirocrewpinned KiroCrew0.3.0. Upstream's current stable release isv0.4.1, so new installs were landing several releases behind.The subtlety this PR turns on: the pin is an artifact version, not a release
tag. The pack passes
--versionstraight through to the upstream installer,which builds both
cli/<channel>/<version>/cli-manifest.jsonandkirocrew-<version>-py3-none-any.whlfrom it. Upstream tags the releasev0.4.1but publishes the CLI artifact as0.4.1rc1, so pinning the tagstring does not resolve.
Measured against the CDN the installer actually fetches from:
cli-manifest.jsonstable/0.4.1stable/0.4.1rc1stable/0.3.0(old pin, control)Corroborating:
feed/stable/latest-cli.jsonreportsversion: 0.4.1rc1withwheel_url .../cli/stable/0.4.1rc1/kirocrew-0.4.1rc1-py3-none-any.whl, and ahost already tracking the stable lane reports
kirocrew 0.4.1rc1.Pinning
0.4.1would have 403'd every KiroCrew install — precisely thefailure mode this parameter's own documentation warns about.
What changed
0.4.1rc1in theinstall.shpack_config_getfallback and themanifest.yamlparam default.published artifact version rather than the GitHub tag, and to point at
feed/stable/latest-cli.jsonas the way to confirm a pin before changing it.The previous wording (
0.4.1 was cut on the stable lane only) was alsoinaccurate — a
v0.4.1-insider.1prerelease exists and Insider carries adistinct version identifier, so the old text gave Insider users no usable
guidance.
version pin consistencytest assertingmanifest default == code fallback == help default. The pinned version livesin three independent places and nothing previously stopped a bump from
leaving one stale; the existing tests only checked that defaults exist and
that
--helpexits 0.No behavioural change beyond the pinned value: the channel/version coupling is
unchanged, and an unpublished pair still fails closed.
Tests
packs/kirocrew/test.sh— 75/75 pass (73 before; +2 new assertions).9.9.9in an isolated copy fails withpin disagrees: manifest='9.9.9' code='0.4.1rc1' help='0.4.1rc1', so itcatches drift rather than passing vacuously.
bash -nclean oninstall.shandtest.sh;git diff --checkclean.shellcheck -S warningclean ontest.sh;install.sh's warning set isidentical to
origin/main(3 × SC2034, pre-existing).Install was not executed end-to-end against the CDN from CI; the pin is
validated by direct manifest/wheel HTTP probes and the stable feed, as above.
no linked issue: requested directly as a dependency-pin refresh, not filed as a bug. The regression test added here is the durable artifact.