Release v0.16.2 - xchain-node carrier - #41
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Carrier for the v0.16.2 patch train. The manifest is generated by
bin/write-release-manifest.jsfrom the actual tagged master merge commits, never by hand.What moves
xchain-vm,xchain-contracts,xchain-regtest-minerOnly
xchain-hubmoves in this train;xchain-indexerkeeps the 0.16.1 it shipped under in the previous one.Why
State-neutral hub fix. The llm attestation provider's default transport spawns a CLI by name, and
resolveHubLlmAuthprefers that transport over an API key wheneverHUB_CLAUDE_CONFIG_DIRis set, but the hub Dockerfile never installed the binary. Measured on BTC testnet: request0dfcea87was admitted at height 151599, ran about 90 consensus rounds over three hours, and expired at 151619 with zero responses, every seated hub reportingprovider_error.It was a rebuild-recurring regression rather than a one-time omission: the fleet ran for twelve days on a hand-built image carrying the binary, and the v0.16.0 roll rebuilt that tag from a Dockerfile that had never installed it. The fix is the recipe plus a guard that asserts the recipe rather than a running container.
No activation height moves and no derived state changes, so the rolling upgrade window cannot create a fork. A validator that serves no llm provider is unaffected.
Release commit audit
src/release-manifest.json(generated),package.jsonandpackage-lock.jsonversion fields 0.16.1 to 0.16.2, the README version badge, and a CHANGELOG entry. Nothing else.check-tag-version-parity --expect 0.16.2 --repos xchain-node: OK.Component tags this manifest pins
Both pushed and verified before the manifest was generated, which is what the generator requires (tag exists at origin, reachable from that repo's
origin/master, GPG-signed by the platform release key):xchain-hubv0.16.2 at98dff5f, taggerreleases@xchain.io, GitHubverified: truexchain-documentationv0.16.2 at1b9b61f, taggerreleases@xchain.io, GitHubverified: true