docs: Versions table in installation.md still lists v0.6.0 for Arc Testnet (current: v0.7.3)

[Sertug17]

Summary

The Versions table in docs/installation.md lists v0.6.0 as the required version for Arc Testnet, but the current release is v0.7.3.

Current state

Network	Version
Arc Testnet	v0.6.0

Impact

A node operator following the installation guide will install v0.6.0, which cannot sync with Arc Testnet. Per BREAKING_CHANGES.md:

"testnet node operators must use v0.7.2 before timestamp 1781791200 (2026-06-18 14:00:00 UTC), when Zero7 activates on testnet. Earlier versions are not supported."

That deadline has passed. v0.6.0 nodes are no longer compatible with the testnet network.

Expected state

Network	Version
Arc Testnet	v0.7.3

Fix

Update the Versions table to reflect the current release. Happy to open a PR.

[osr21]

Confirmed, and it's slightly worse than the summary states — two additions worth folding into the PR you offered:

1. The incompatibility date is earlier than the Zero7 quote suggests. BREAKING_CHANGES.md also carries the v0.7.1 note: testnet operators needed v0.7.1 before timestamp 1779894517 (2026-05-27 15:08:37 UTC), when Zero5/Zero6 activated. So v0.6.0 has been unable to follow testnet since May 27, not June 18 — the table has been pointing at a dead version for over two months.

2. Same file, line ~64: the arcup --install v0.6.0 example. The install-a-specific-version snippet uses the same stale tag, so a fix that only touches the table leaves the doc contradicting itself one section down. Worth updating both in one pass. (For completeness: the other v0.6.0 hits in the repo — crates/quake/src/cli_version.rs, setup.rs, the quake README, CI workflows — are test fixtures and version-compat boundary cases where v0.6.0 is the point; they should not be touched.)

On blast radius: the table drives both install paths — the binary path via the arcup --install <version> example and the source path via git checkout $VERSION ("Refer to the Versions section to find out which one to use"). An operator following either lands on a node that starts cleanly and then stalls at the fork boundary, which is a confusing failure mode with no error pointing back at the version choice.

Root cause worth a thought in the same PR: the table has now drifted through three releases (v0.7.1, v0.7.2, v0.7.3) without an update, which suggests it will drift again. Two cheap options: (a) replace the pinned version with a link to the latest release plus a pointer to BREAKING_CHANGES.md for fork deadlines, keeping a pinned tag only where reproducibility matters; or (b) keep the pin but add a release-checklist item / CI grep that fails when installation.md doesn't mention the tag being released. Either turns this from a recurring doc bug into a one-time fix.

Happy to review the PR when it's up.