To upgrade an xOne client, find the release, fetch its asset, check the file and the version stamp, upgrade a follower first, and prove the start. Upgrade a producer only after a follower has run the same tag. This post is the short checklist. The long guides are linked from each step. xOneTS, xOnePy and xOneC are private repositories. Their links need access.

Where is the release, and what do I fetch?

List the releases of each repository with gh release list. Fetch the listed asset and SHA256SUMS from the same release.

gh release list -R XDCIndia/xOneRS
gh release download v0.1.0 -R XDCIndia/xOneRS -p 'xone-v0.1.0-linux-amd64' -p SHA256SUMS
REFERENCE TABLEScroll to explore all columns →
Client Latest tag (published, UTC) Asset to fetch Stamp command
xOneRS v0.1.0 (2026-11-12) xone-v0.1.0-linux-amd64 xone --version
xOneTS v0.1.0 (2026-11-12) xonets-v0.1.0-linux-amd64 xonets --version
xOnePy v0.1.1 (2026-11-13) the wheels of all packages, for example xonepy_node-0.1.1-py3-none-any.whl xonepy --version
xOneC v0.1.0 (2026-11-14) xonec-v0.1.0-linux-amd64 xonec --version

xOnePy also has v0.1.0, published on 2026-11-13. See how releases are made for the list and the stamp format.

How do I check the file?

Run sha256sum -c SHA256SUMS, then read the stamp. Use --ignore-missing when you downloaded only some of the files. The steps, and what they cannot prove, are in verify a release artifact.

The rules for a good stamp differ by client. The release rulebooks of xOneTS, xOnePy and xOneC say this:

  • xOneTS and xOnePy: a stamp with 00000000 or -dirty is a failed build.
  • xOneC: a stamp with 00000000 is a failed build. The stamp has no -dirty marker.
  • xOneRS: the stamp must have no unknown and no -dirty. The tool ops/tools/xone-release-check.py and the script ci/qualify-artifact.sh are described in the verify post.

In which order do I upgrade?

Followers first. Then producers, one at a time. The xOneRS runbook ops/upgrade-rollback.md says a producer host is upgraded only with the owner present. The commands are in the upgrade and rollback guide.

The follower soak rule is in docs/ops/release.md. A net2040 follower and an Apothem follower must each pass it before a producer runs the tag:

  • 24 hours or more, across at least one epoch switch.
  • 0 refused blocks, the head within 10 minutes of the tip, and xone --version equal to the tag.
  • No restart that the operator did not start.

The rule is written for xOneRS. The three other rulebooks do not repeat it.

What do I check after the start?

Check that the clientVersion equals the version of the binary, and that the head rises. For xOneTS, xOnePy and xOneC, the release rulebook says the clientVersion of the node's board entry must equal --version. For xOneRS, run the version script:

ops/xone-version.sh <instance>

It compares the installed xone --version, the running process and web3_clientVersion. It exits 0 when all match, 1 on a mismatch or a stale process, and 3 when a stamp could not be read. The runbook also asks you to read eth_blockNumber before and after the start. The head must be at or above the first value, and it must rise.

How do I roll back?

An older binary refuses a newer datadir. Back up the whole datadir before you swap the binary. The runbook tells you to read the "datadir format" line of the release notes first.

  • Format unchanged: put the old binary back and start it.
  • Format changed: restore the backup. The helper ops/tools/xone-rollback-restore.sh does this step and keeps the current safety record.

Never lower the signer safety record. The runbook asks you to stop and ask the owner if a step would lower, delete or replace it. The record is at <datadir>/xone/safety. Issue #820 fixed the old path in the runbook and is closed. No runbook for the other three clients exists on main. Take a backup before you swap any binary.

Which release defects are open?

Two. Both issues are open on 2026-11-15.

REFERENCE TABLEScroll to explore all columns →
Issue Client Defect What to do
xOneRS#894 xOneRS The v0.1.0 binary is dynamically linked and needs GLIBC_2.38. It is 19,066,296 bytes, above the 18 MiB default size budget of ci/release.sh. The release gate requires a static musl build. Run file on the download. On a host with an older glibc, expect the binary to fail.
xOnePy#107 xOnePy A fleet follower answers web3_clientVersion with xOnePy/v0.1.1-00000000-00000000/.... The cause is a build or an install without build data. Build wheels with python3 tools/build.py <dir>. Treat a 00000000 stamp as a failed build.

How do other clients describe upgrades?

REFERENCE TABLEScroll to explore all columns →
Client What the project says xOne
ethrex Upgrades are a drop-in restart. As stated in Six months of ethrex in production, 2026-07-20. A follower soaks first. A newer datadir under an older binary is refused.

Frequently asked questions

Which client is on which version today?

xOneRS, xOneTS and xOneC are at v0.1.0. xOnePy is at v0.1.1. Run gh release list -R XDCIndia/<repo> for the current list.

Can I upgrade a producer first?

No. A producer runs a tag only after a follower has run it. The soak needs 24 hours or more and one epoch switch.

How do I know the running node is the new release?

The clientVersion must equal --version. For xOneRS, ops/xone-version.sh <instance> compares both and the running process.

Is the xOneRS v0.1.0 binary static?

No. Issue #894 records that it is dynamically linked and needs GLIBC_2.38. The issue was closed on 2026-11-15 by a republish helper (PR #1120), but the release assets had not been replaced when we checked.

Sources