Skip to content

openvmm: define the product version in the workspace - #4132

Open
benhillis wants to merge 2 commits into
microsoft:mainfrom
benhillis:user/benhill/openvmm-version-source-final
Open

openvmm: define the product version in the workspace#4132
benhillis wants to merge 2 commits into
microsoft:mainfrom
benhillis:user/benhill/openvmm-version-source-final

Conversation

@benhillis

Copy link
Copy Markdown
Member

OpenVMM needs one product version that travels in the source tree, because the release artifact is source that another party builds later without Git history.

This change:

  • defines the canonical version in [workspace.package];
  • has the openvmm and openvmm_entry crates inherit it;
  • reports it through openvmm --version and Windows VERSIONINFO;
  • retains the most recently released version until a reviewed PR selects the next release;
  • preserves OPENVMM_PKGVERSION for builders that need to identify their own package;
  • extends the house-rules lint to allow only the crates that intentionally carry versions.

This is the first independently reviewable change in the source-release series. It does not add Git probing, release automation, or archive assembly.

Ben Hillis added 2 commits July 31, 2026 11:55
`openvmm --version` did not exist, and there was nothing to report if it had:
the workspace set no `version`, so every crate in it was `0.0.0`.

OpenVMM ships as a source archive that packagers build themselves, which rules
out the usual approach of having CI inject a version at build time -- the
packager builds long after our pipeline has exited, from a tree with no git
history to recover a version from. The version therefore has to be committed to
the tree. QEMU, systemd, the kernel, cloud-hypervisor and rustc all do this, and
each falls back gracefully when `.git` is absent rather than deriving the
release version from a tag.

So: set `version` in `[workspace.package]`, inherit it in `openvmm` and
`openvmm_entry`, and wire up clap's `version`. `OPENVMM_PKGVERSION` lets a
packager append their own build identity, as QEMU's `-Dpkgversion` and
cloud-hypervisor's `CH_EXTRA_VERSION` do; an empty value is ignored, since build
systems routinely pass an undefined variable through as "".

Two things fall out of that:

- The Windows VERSIONINFO resource is a second version surface, stamped from
  `OPENVMM_MAJOR`/`MINOR`/`PATCH`/`REVISION` and defaulting to `0.0.0.0`. No
  in-repo caller sets those, so leaving it alone would have left one binary
  reporting `0.1.0-dev` from `--version` and `0.0.0.0` from its file properties.
  It now defaults to the crate version, with the env vars still overriding
  per-component so a pipeline can stamp a build number in.

- `cargo xtask fmt` deliberately strips `version` from `[package]`, partly
  because doing so also makes a crate unpublishable. The three crates on its
  exception list now set `publish = false` explicitly, restoring the property
  the lint was relying on.

Verified by building `openvmm` from an extracted archive with no `.git` anywhere
above it, which is the case that actually matters.
The workspace version advances only in the reviewed pull request that selects the next release. Development-build identity is added separately from the committed product version.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 0ba1c0df-faf0-4a0e-b39d-c3eb0e363fce
@benhillis
benhillis requested a review from a team as a code owner July 31, 2026 19:48
Copilot AI review requested due to automatic review settings July 31, 2026 19:48

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR establishes a single canonical OpenVMM “product version” in the workspace manifest so that version information is preserved in source releases (without relying on Git history), and wires that version into user-visible reporting and Windows resource stamping.

Changes:

  • Define the canonical version in [workspace.package] and have openvmm / openvmm_entry inherit it.
  • Update openvmm_entry to report the intended version via openvmm --version, with an optional OPENVMM_PKGVERSION override for downstream packagers.
  • Extend the xtask house-rules lint allowlist for crates that intentionally carry versions, and add publish = false to those crates’ manifests.

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
xtask/src/tasks/fmt/lints/package_info.rs Expands version allowlist and documents why certain crates may carry versions.
vm/vmgs/vmgstool/Cargo.toml Adds publish = false alongside its explicit version.
openvmm/openvmm/Cargo.toml Inherits workspace version and sets publish = false.
openvmm/openvmm/build.rs Defaults Windows VERSIONINFO stamping to the crate/workspace version unless overridden by OPENVMM_*.
openvmm/openvmm_entry/src/cli_args.rs Sets the CLI-reported version (with OPENVMM_PKGVERSION override) and pins command name to openvmm.
openvmm/openvmm_entry/Cargo.toml Inherits workspace version and sets publish = false.
Cargo.toml Introduces [workspace.package].version as the canonical version.
Cargo.lock Updates resolved versions for openvmm and openvmm_entry to match the workspace version.

Comment thread openvmm/openvmm/build.rs
Comment on lines +27 to +31
let component = |var: &str, from_crate_version: &str| {
std::env::var(var)
.or_else(|_| std::env::var(from_crate_version))
.map(parse_u16)
.unwrap_or(0)
Comment on lines +35 to +39
/// List of packages that are allowed to have a version.
///
/// Each of these must also set `publish = false`, since carrying a version
/// forfeits the implicit publishing protection described at the module level.
///
Comment on lines +144 to +145
/// identity in, the way QEMU's `-Dpkgversion` and cloud-hypervisor's
/// `CH_EXTRA_VERSION` do. Distributions use this so a bug report names the

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not reference other VMMs in comments.

Comment on lines +151 to +154
const VERSION: &str = match option_env!("OPENVMM_PKGVERSION") {
Some(v) if !v.is_empty() => v,
_ => env!("CARGO_PKG_VERSION"),
};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have an openvmm_version crate that defines this?

@github-actions

github-actions Bot commented Aug 1, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants