v0.9.0 tag has workspace version 0.8.7-nightly, so builds from the tag report the wrong version
Lore version
v0.9.0 tag, which reports itself as lore 0.8.7-nightly+0
Installation method
Built from source
Operating system / architecture
Linux (Ubuntu 22.04, WSL2) / x86_64
Steps to reproduce
git clone --branch v0.9.0 https://github.com/EpicGames/lore
cd lore
grep -m1 '^version' Cargo.toml
cargo build --release -p lore-client
target/release/lore --versionExpected vs actual behavior
Expected: a build from the v0.9.0 tag reports version 0.9.0.
Actual:
version = "0.8.7-nightly"
lore 0.8.7-nightly+0The prebuilt release artifacts do report the right version (loreserver --version from the v0.9.0 release prints loreserver 0.9.0), so the release pipeline stamps the version somewhere outside the tagged tree, while build-helper.rs falls back to CARGO_PKG_VERSION for everyone building from the tag.
Why it matters: bug reports from anyone building from source carry a version string that does not match any release, and "0.8.7-nightly" reads as older than v0.8.6. This is already happening: #181 is filed against "lore 0.8.7-nightly+0, built from source", which could be anything from post-0.8.6 main up to and including v0.9.0. Building from source is also the only option on Ubuntu 22.04 today (#143), so this affects a meaningful share of Linux users.
Suggestion: bump [workspace.package].version to the release version as part of cutting the tag (and back to the next -nightly afterwards), or have build-helper.rs derive the version from git describe --tags when available and fall back to CARGO_PKG_VERSION only when it is not.
Component
Release process / build-helper.rs
Source: EpicGames/lore