Skip to content

session-peer v1.0.0-rc.4

Pre-release
Pre-release

Choose a tag to compare

View all tags
@abruption abruption released this 23 Sep 08:33
v1.0.0-rc.4
60f7f8b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

session-peer v1.0.0-rc.4

RC4 fixes forward from a partial RC3 publication: PyPI accepted the RC3 wheel, but the sdist upload failed after repeated HTTP 502 responses. RC3 is not promotable. RC4 changes the package version and release documentation only; its runtime behavior is the reviewed #162 and #168 implementation. Stable users should remain on v0.9.2 unless explicitly testing this prerelease.

Changes since RC2

  • #162 preserves the fail-closed route contract while adding sanitized per-attempt stages and opt-in diagnostic events. A bounded control/admission setup retry happens only before application submission; messages are never replayed.
  • #168 keeps receiver reconnect delay at 0.5 seconds after a normal idle expiry, uses 10/10-second Relay-leg ping, and adds receiverRoleBusy and clientRoleBusy counters.
  • #163 offline reproductions show reduced amplification of a stalled path, not a repair of that path or proof that #161 is resolved.

Install after complete publication

Use the exact candidate with the existing package manager on both paired endpoints. Do not replace another installation manager or install from RC3's incomplete file set.

# Unix / WSL with relay and MCP
pipx install 'session-peer[relay,mcp]==1.0.0rc4'
# Native Windows core and MCP, without relay
pipx install 'session-peer[mcp]==1.0.0rc4'

The Python/PyPI version is 1.0.0rc4; the GitHub tag is v1.0.0-rc.4. The core requires Python 3.9+, MCP requires 3.10+, and receiver/Relay runtime requires Unix or WSL with 3.11+.

Service environment: a macOS or Linux receiver started by launchd or systemd must have the directory of the target TUI's codex executable on its PATH; otherwise Codex deliveries fail as native_outcome_unknown. The RC4 validation rerun completed without operational failures after only that directory was added to the receivers' service PATH. See the paired-device guide, #171 and #176.

Evidence and remaining gates

The RC2 four-hour campaign ended at minute 172 without a completion record. Keep #161, #163 and #164 open until the exact fully published RC4 passes five-host validation. A posted or queued message is not a consumed ACK; without independent observation, consumptionConfirmed: false remains the correct result.

Post-publication validation plan

  1. Verify the published tag and commit, both PyPI file hashes, fresh wheel and sdist installations, prerelease status and stable v0.9.2 latest status.
  2. Back up installation files and approved consistent state snapshots before installing the exact RC4 on Mac mini, MacBook, quintet-desktop (native and WSL), KR and US. Preserve device identities, policy and replay state.
  3. Run the #164 five-host four-hour campaign in an independent process with a complete or aborted record: health each minute, probes at least five minutes apart per receiver, diagnostic events, per-minute receiverRoleBusy/clientRoleBusy, independent ACKs at T0/T2h/T4h, and one Relay restart at T2h with a 60-second recovery target.
  4. Classify every failure by stage. Unexplained failures, missing ACKs or an incomplete run block promotion. Do not close the milestone merely because publication or PR merges succeeded.

Release boundaries

Preparation alone is not publication or fleet validation. Antigravity remains experimental, and hosted Relay/OAuth health is separate from package availability. Never retry an outcome-unknown message or change inbound permissions to force an ACK.

Assets 2
Loading