#200·lore

v0.9.0 tag has workspace version 0.8.7-nightly, so builds from the tag report the wrong version

Author: ooo27Created Sep 10, 2026Updated Sep 10, 2026

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

bash
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 --version

Expected 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+0

The 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