Duplicate check
Problem
san currently does not ship with a built-in command-line tool, which makes it inconvenient for users to check the
current version or upgrade to the latest release. It would be great if the project provided a standard set of CLI
subcommands to improve the overall developer experience.
Proposed solution
dd the following subcommands (most important ones listed first, more can be added later):
- san version
• Print the current san version, build time, Go version, and other basic build info
• Support a --json flag for machine-readable output (useful for scripts)
Example:
$ san version
san version 1.2.3
build: 2026-07-10
go: go1.22
$ san version --json
{
"version": "1.2.3",
"build_time": "2026-07-10",
"go_version": "go1.22",
"commit": "abc1234"
}
- san update
• Check for new releases and upgrade san itself
• Support the following modes:
• san update — check and upgrade to the latest stable release
• san update --check — only check for updates, do not download
• san update --version v1..2.3 — upgrade to a specific version
• san update --force — force overwrite the local binary
• Automatically back up the current binary before upgrading
• Roll back automatically on failure
Example:
$ san update --check
Current version: 1.2.3
Latest version: 1.3.0
A new release is available. Run `san update` to upgrade.
$ san update
Downloading san v1.3.0...
Backup created at /usr/local/bin/san.bak
Update successful. Please restart your shell.
- Nice-to-have additions
• san doctor — self-check the environment (dependencies, network, config)
• san completion — generate shell completion scripts (bash / zsh / fish / powershell)
• san info — dump runtime info (OS, arch, config paths) for bug reports
Use Cases
• Developers: quickly verify which version is installed locally
• DevOps / SRE: roll out upgrades across CI runners or production hosts
• Troubleshooting: confirm version info as the first step when filing bug reports
Implementation Suggestion
If the team is open to it, splitting the CLI into its own package (e.g. cmd/san) and using cobra
https://github.com/spf13/cobra would make it easier to add more subcommands in the future and keep argument parsing
consistent.
Happy to send a PR if the maintainers agree on the direction. Thanks!
Alternatives considered
No response
Duplicate check
Problem
san currently does not ship with a built-in command-line tool, which makes it inconvenient for users to check the
current version or upgrade to the latest release. It would be great if the project provided a standard set of CLI
subcommands to improve the overall developer experience.
Proposed solution
dd the following subcommands (most important ones listed first, more can be added later):
• Print the current san version, build time, Go version, and other basic build info
• Support a --json flag for machine-readable output (useful for scripts)
Example:
• Check for new releases and upgrade san itself
• Support the following modes:
• san update — check and upgrade to the latest stable release
• san update --check — only check for updates, do not download
• san update --version v1..2.3 — upgrade to a specific version
• san update --force — force overwrite the local binary
• Automatically back up the current binary before upgrading
• Roll back automatically on failure
Example:
• san doctor — self-check the environment (dependencies, network, config)
• san completion — generate shell completion scripts (bash / zsh / fish / powershell)
• san info — dump runtime info (OS, arch, config paths) for bug reports
Use Cases
• Developers: quickly verify which version is installed locally
• DevOps / SRE: roll out upgrades across CI runners or production hosts
• Troubleshooting: confirm version info as the first step when filing bug reports
Implementation Suggestion
If the team is open to it, splitting the CLI into its own package (e.g. cmd/san) and using cobra
https://github.com/spf13/cobra would make it easier to add more subcommands in the future and keep argument parsing
consistent.
Happy to send a PR if the maintainers agree on the direction. Thanks!
Alternatives considered
No response