How xOne releases are made, and how to read the version stamp

Current releases

xOnePy also has v0.1.0, published on 2026-11-13. The other three clients have one tag each.

Read the version stamp

Every client prints one stamp. The format is the same in all four, with a different client name and toolchain field:

xOneRS/v0.1.0-d1d6c3f5-14112026/linux-x86_64/rustc1.94.0

The date field does not mean the same thing in every client:

• xOneRS release builds set it to the commit date. The release script sets SOURCE_DATE_EPOCH to the commit time, so every rebuild of a tag gives the same stamp.
• xOneTS and xOnePy use the UTC build date.
• xOneC uses the commit date.

The stamp is one value. web3_clientVersion, the P2P hello and ethstats read the same string. The word unknown must not appear in it. A release build refuses a stamp with unknown or -dirty. xOneTS, xOnePy and xOneC show 00000000 for the commit and date when the build has no git data, and treat that stamp as a failed release build.

Print it

xone --version      # xOneRS; the short form is -V, and "xone version" also works
xonets --version    # xOneTS
xonepy --version    # xOnePy
xonec --version     # xOneC

On a running node, the clientVersion that SkyNet shows must equal this output. The xOneTS, xOnePy and xOneC rulebooks make this the last step of a release.

One note on names. xOneRS was called xOne until 2026-11-14. The v0.1.0 release page and the older docs still show stamps that start with xOne/. The code on main now builds xOneRS/.

What is in xOneRS v0.1.0

From CHANGELOG.md:

• One binary, xone, with crates for XDPoS V1 and V2 consensus, EVM, state, networking, snap sync, RPC, signer and block builder.
• Sync modes: full, snap, fast (an alias of snap, as in geth-XDC), minimal and archive.
• On net2040 on 2026-11-12, each of snap, fast and minimal sealed 3 of 3 eligible turns on a borrowed seat. The changelog calls three seals a smoke test, not reliability evidence.
• Known gaps, listed by issue number, for example #122: eth_subscribe newHeads and logs return an id but deliver no notification.

The changelog of main also has an Unreleased section. It covers --eth.requiredblocks and the three parts of --state.disk. These are not in any tag yet.

The other changelogs have the same shape: what is in the release, proof on a live network, known gaps. xOnePy v0.1.1 has one entry: the wheels now carry the forks table and genesis files, so an installed wheel starts a node. xOneC v0.1.0 lists, among its gaps, that the release was not re-gated on its own commit.

How a release is cut

The release steps in the xOneRS docs:

1. main is green. The gate that the release claims is recorded. A PR bumps the workspace version and CHANGELOG.md.
2. The owner tags vX.Y.Z on the merge commit. The tag must equal v<workspace version>.
3. On a clean checkout of the tag, ci/release.sh builds the artifacts.

The script refuses a dirty tree, a HEAD that is not at a tag, a tag that differs from the workspace version, a stamp that differs from the tag and commit, and a missing signing key. It also refuses a binary that is not static, has GLIBC symbols, or is over the size budget.

The documented output is a static musl tarball per architecture, an SBOM, a provenance file, SHA256SUMS and a detached signature. Two limits apply today. The release page for v0.1.0 lists the binary and SHA256SUMS only. And docs/ops/release.md says no release key exists yet: that is an open owner decision.

Release checks

• Rehearsal. ci/test-release.sh builds the same tag in two clones at different paths. The recorded run gave equal SHA-256 for binary and tarball. A second test on two hosts, on 2026-11-14, also gave equal hashes. Its limits: same OS release and gcc, glibc target only, no signing.
• Packaging. ci/test-packaging.sh checks the systemd unit and the launcher script.
• Follower soak. A producer runs a tag only after a follower has run it. Each of a net2040 follower and an Apothem follower runs at least 24 hours and across at least one epoch switch. The pass rule is 0 refused blocks, a head within 10 minutes of the tip, and --version equal to the tag.
• Upgrade and rollback. ops/upgrade-rollback.md has the steps. Followers go first. A producer host is upgraded one at a time with the owner present. A newer datadir under an older binary is always refused. If the format changed, rollback means restoring the pre-upgrade backup. The runbook never lowers the signer safety record. A loopback rehearsal covered the upgrade, a rollback with an unchanged format, and a restore from the backup. It did not cover a format migration or a signer.

One rulebook

The xOneTS, xOnePy and xOneC release pages say they are mirrored from the Rust client rulebook, and that the rule numbers are the same. The same rules apply to all four: work goes to main through PRs, the owner merges and releases, a release comes from a clean checkout of the tag, and the stamp must match.

The Rust docs hold the heavier checks. The other three rulebooks do not include a rehearsal or an upgrade runbook.