What problem does your feature solve?
The stellar-cli version is rendered inconsistently depending on how the CLI was installed. The same 26.0.0 release ends up as three different strings in the cliver meta of a built contract — and in the stellar version output — depending on the install method. This was raised in #2525 (comment).
Today, cliver (and stellar version) renders as {pkg}#{git} where {git} is whatever crate_git_revision produces at build time. That depends on the install path:
Homebrew (built from a crates.io tarball with no git context):
Cargo crates.io install (commit hash recorded in the package metadata):
cliver: 26.0.0#60f7458e7ecffddf2f2d91dc6d0d2db4fab03ecc
Cargo git install (built from a git checkout — git describe output):
cliver: 26.0.0#v20.0.0-836-gfe07b3678833e07c43235a6caaeccff81e146856
Three different strings for the same release makes downstream tooling (verifiers, registries, indexers) unable to reliably parse, compare, or validate the field, and makes verify's "expected vs. running" mismatch detection fragile.
What would you like to see?
Normalize the rendering of the stellar-cli version so it is always emitted in exactly one form, regardless of how the CLI was installed:
26.0.0#60f7458e7ecffddf2f2d91dc6d0d2db4fab03ecc
That is: {semver}#{full-40-char-commit-sha}.
This normalization should apply to both:
- The
stellar version command output
- The
cliver meta embedded into wasm during contract build
Once normalized, the format becomes a stable contract that:
What alternatives are there?
- Document the three formats and have downstream tooling parse all of them. Cheaper short-term but pushes complexity onto every consumer of
cliver forever, and leaves verify mismatch detection brittle which is already creating problems.
- Drop the commit sha entirely and embed only
{semver}. Simpler, but loses the ability to identify exactly which commit a build came from — important for security-relevant verification of contract builds.
- Keep the semver-only format for release builds and only embed the sha for unreleased / dev builds. A middle ground, but produces two formats again.
What problem does your feature solve?
The stellar-cli version is rendered inconsistently depending on how the CLI was installed. The same
26.0.0release ends up as three different strings in theclivermeta of a built contract — and in thestellar versionoutput — depending on the install method. This was raised in #2525 (comment).Today,
cliver(andstellar version) renders as{pkg}#{git}where{git}is whatevercrate_git_revisionproduces at build time. That depends on the install path:Homebrew (built from a crates.io tarball with no git context):
Cargo
crates.ioinstall (commit hash recorded in the package metadata):Cargo
gitinstall (built from a git checkout —git describeoutput):Three different strings for the same release makes downstream tooling (verifiers, registries, indexers) unable to reliably parse, compare, or validate the field, and makes
verify's "expected vs. running" mismatch detection fragile.What would you like to see?
Normalize the rendering of the stellar-cli version so it is always emitted in exactly one form, regardless of how the CLI was installed:
That is:
{semver}#{full-40-char-commit-sha}.This normalization should apply to both:
stellar versioncommand outputclivermeta embedded into wasm duringcontract buildOnce normalized, the format becomes a stable contract that:
clivermachine-parseable with a single regexverify's mismatch detection meaningful (currently a homebrew-built26.0.0and a crates.io-built26.0.0would produce differentcliverstrings even though they are the same released CLI)cliveris normalized to this single shapeWhat alternatives are there?
cliverforever, and leavesverifymismatch detection brittle which is already creating problems.{semver}. Simpler, but loses the ability to identify exactly which commit a build came from — important for security-relevant verification of contract builds.