DRAFT - POC for managing version across binaries

[cipherzzz]

This pull request introduces several changes to the stacks-common and stacks-signer modules to enhance version handling and improve code organization. The most important changes include the addition of a new versions module, updates to the Cargo.toml file, and modifications to the build.rs file to handle version information more efficiently.

Enhancements to version handling:

• stacks-common/src/util/versions.rs: Added a new versions module that includes functions to retrieve and format build versions for different binaries.
• stacks-common/build.rs: Introduced a new Versions struct and functions to read version information from a versions.yaml file and override it with environment variables if they exist.

Code organization improvements:

• stacks-common/Cargo.toml: Reformatted the authors and keywords fields for better readability and added new dependencies for serde and serde_yaml. [1] [2] [3]
• stacks-common/src/util/mod.rs: Added the newly created versions module to the list of public modules.

Updates to stacks-signer:

• stacks-signer/src/libsigner.rs: Replaced the manual version string construction with the new get_long_version function from the versions module.
• stacks-signer/src/main.rs: Integrated the get_build_version function from the versions module to retrieve build version information.

Description

Applicable issues

• fixes #

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[cipherzzz]

@wileyj @hstove

# cd stacks-signer dir
STACKS_SIGNER_VERSION=3.2.1.0 cargo build

# cd targets/debug
./stacks-signer --version

[hstove]

FYI this already has a --version command in line 46

[hstove]

I don't think we need serde_yaml outside of build_dependencies

[hstove]

We already have the version_string util, which includes the arch, build type, and also git info. I think we should keep that, as it's also a part of our CI process (ie setting the git info via ENV).

[hstove]

IMO, you should rebase this on top off #5399. That PR uses a "proper" build script to generate static types from a versions file, which is better / more performant than parsing YAML at runtime. Then, this PR can be just about adding a --version flag to our existing CLIs.

Additionally, I don't think we should be tracking individual versions other than the stacks node version and signer version. We've never made separate releases for other binaries (like stacks-inspect), and I don't suspect we'll have reason to do so in the future.

[hstove]

Nice work on opening your first PR btw! 👊

[cipherzzz]

@hstove @wileyj - It looks like the heavy lifting is already done in #5399 . So, the remaining work is just to

• Integrate a version to the remaining binaries
  • I assume you want to use the stacks-node version for these remaining cli versions - and keep the signer version separate?

[hstove]

@cipherzzz yep!