You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently I have to run a small script just to be able to determine what the current release is. Omitting the version number results in .dev builds being installed.
Initial and subsequent installs should only use released versions, automatically. Similar to the copilot cli, the specify cli should indicate when there is an upgrade available and should be capable of self updating, OR there should be a way to refer to an @latest tag only.
Hi @rcollette and @mnriem — I think a useful small PR here would be a read-only specify upgrade --check subcommand that:
calls the GitHub Releases API and compares it with the installed version
prints the upgrade command if a newer release exists
avoids any destructive action and does not try to detect the user's install method in this PR
falls back gracefully when offline or rate-limited
A new upgrade subcommand seems like a better fit than extending specify version, since version is a local-info command today, and specify integration upgrade already establishes upgrade as the verb in Spec Kit.
A follow-up PR could later add specify upgrade --apply for the actual self-update flow. I kept that out of scope here because it would need install-method detection (uv tool, uvx, source checkout, etc.) and failure/recovery handling, which seem like a design discussion of their own.
One design question before I start: should bare specify upgrade behave like --check, or should --check be required until --apply exists?
Thank you @rcollette for raising the original issue and describing the upgrade pain point clearly. It took quite a while to get this over the line, but the review rounds made the final result much better.
Activity
chordpli commentedon Apr 22, 2026
Hi @rcollette and @mnriem — I think a useful small PR here would be a read-only
specify upgrade --checksubcommand that:A new
upgradesubcommand seems like a better fit than extendingspecify version, sinceversionis a local-info command today, andspecify integration upgradealready establishesupgradeas the verb in Spec Kit.A follow-up PR could later add
specify upgrade --applyfor the actual self-update flow. I kept that out of scope here because it would need install-method detection (uv tool,uvx, source checkout, etc.) and failure/recovery handling, which seem like a design discussion of their own.One design question before I start: should bare
specify upgradebehave like--check, or should--checkbe required until--applyexists?If that scope sounds right, I can take it.
mnriem commentedon Apr 22, 2026
Go for it, but will a small change. Please introduce
specify self checkandspecify self upgradefeat(cli): add specify self check and self upgrade stub (#2316)
chordpli commentedon Apr 23, 2026
Following up on Phase 1, I’d like to continue with Phase 2 as well. I’ll make sure to implement it as you intended, @rcollette @mnriem
feat(cli): implement specify self upgrade
feat(cli): implement specify self upgrade
chordpli commentedon Jun 4, 2026
This has finally landed via #2475.
Thank you @rcollette for raising the original issue and describing the upgrade pain point clearly. It took quite a while to get this over the line, but the review rounds made the final result much better.
Thanks again for bringing this up.
feat(cli): add specify self check and self upgrade stub (github#2316)