Add default version to version_string function

[hstove]

This PR updates the version_string function, along with our release process docs, to add a "hard-coded" version. When the STACKS_NODE_VERSION environment variable is not present (such as when building from source), the resulting version string will contain this default value.

I tried using the Cargo.toml version, which is a cleaner solution, but cargo is strict about the version format and doesn't allow our versioning scheme.

[wileyj]

this does add a little extra burden. I'd like to first see if there are other options vs what you're doing here (which seems to work fine, but may become a bit messy with several binaries being built).

…

On Tue, Oct 29, 2024 at 10:16 Hank Stoever ***@***.***> wrote: @hstove <https://github.com/hstove> requested review from @stacks-network/blockchain-team on: #5399 <#5399> Add default version to version_string function as a code owner. — Reply to this email directly, view it on GitHub <#5399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVXIHA7GT7EOEWQPDPE6TLZ567IHAVCNFSM6AAAAABQ2LJ5TSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHE4DQNRRGYYTENQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[hstove]

Yeah I'm totally open to other ideas, but at least this only means we update the version in two total places. If we went with the Cargo.toml file, we'd have to change it in a number of different packages.

[wileyj]

What if, instead of updating several source files, we used either a common file or even a text/yml file?

the idea i had was to keep version constants here: stacks-common/src/libcommon.rs
or a dedicated file in that dir that can be used during compile:
./versions.yml or something

[hstove]

@wileyj I've updated this PR to have a top-level versions.toml file (I used TOML because we have toml dependencies elsewhere, so it was just easier/better than a new dep). A build script automatically generates the Rust code for these constants.

[obycode]

This looks good, just had 2 questions. Also, is there a good way to write a test for this?

[hstove]

@obycode regarding "can we test this" - there is this old Rust issue marked "closed as needs RFC" regarding writing tests for a build script. What we would have to do is either:

• If we want to keep toml out of stacks-common deps, then we'd have to make a new workspace package with this code, which we can test as usual. Then, the build.rs script would import that code, and stacks-common would import it as a build dependency
• Add toml to stacks-common and write code & unit tests as usual

[wileyj]

it's feasible, but it would definitely be something custom that at most can compare a changelog version (possibly release branch name) and pattern match to this value. i don't know if there's a way to know if it's correct though.

…

On Wed, Jan 29, 2025 at 10:47 Adriano Di Luzio ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In docs/release-process.md <#5399 (comment)> : > - Create a chore branch from `release/X.Y.Z.A.n`, ex: `chore/X.Y.Z.A.n-changelog`. - Add summaries of all Pull Requests to the `Added`, `Changed` and `Fixed` sections. + - Update the `stacks_node_version` string in [versions.toml](../versions.toml) to match this release. Would it be possible to ensure that building a release fails if this hasn't been updated? We might want to override this check in *some* cases (eg when building from a branch), but I'd like to avoid that we forget updating this when doing releases. CC @wileyj <https://github.com/wileyj> — Reply to this email directly, view it on GitHub <#5399 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVXIHCZVOADT4KNVZJ2NMD2NDZ2VAVCNFSM6AAAAABQ2LJ5TSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKOBRGQ3TMMJZHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hstove]

@wileyj can you take another look at this? Mainly I want your approval (or rejection) based on how this would effect our release process.

[wileyj]

@wileyj can you take another look at this? Mainly I want your approval (or rejection) based on how this would effect our release process.

Looks fine to me! i checked for this PR on the recent release even, and i see it documented as expected.