Repository navigation
chore: move the Rust pin to 1.98.1 - #266
Merged
Merged
Conversation
Latest stable, released 2026-09-01. Measured first, as rust-toolchain.toml requires: `gh workflow run toolchain-ab.yml -f candidate=1.98.1` builds this source with both toolchains in one job and measures them interleaved. On an EPYC 7763 the worst benchmark moved +1.9% against a 1.8% pure-Python control noise floor -- verdict "no significant difference", every gated benchmark flat. That is the bar the pin's own procedure sets. Bumped everywhere the version is named and cargo actually uses it: rust-toolchain.toml's channel, the four publish.yml wheel jobs, the four test.yml jobs that install components for it, and toolchain-ab.yml's baseline default. The history lines in those files keep saying 1.98.0, because that is history. CONTRIBUTING's "the pin has moved on to 1.98.0" now reads "moved on past it", so it stops being a statement that goes stale on every bump. The pin's History comment records this measurement, so the next person bumping it can see what the bar was. Verified on 1.98.1: 867 Python tests, 13 core tests, clippy with -D warnings, fmt. Signed-off-by: kurok <22548029+kurok@users.noreply.github.com>
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
1 participant
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.
Moves the pin from 1.98.0 to 1.98.1 (latest stable, 2026-09-01).
Measured first
rust-toolchain.tomlsays how to do this, and why: the benchmark gate builds a revision and its base with the same toolchain, so a compiler change is the one regression it cannot see. This repo has watched a rustc minor version move the parse path 15–96% (#120).So, per that file:
gh workflow run toolchain-ab.yml -f candidate=1.98.1— one job, both toolchains, measured interleaved.Result on an EPYC 7763: worst benchmark +1.9% against a 1.8% control noise floor. Verdict "no significant difference". Every gated benchmark flat:
parse_messagefull_readparse_treeparse_manyparse_qp_dense_escapesparse_8bit_textWhat changed
Every place the version is named and cargo actually uses it:
rust-toolchain.toml's channel, the fourpublish.ymlwheel jobs, the fourtest.ymljobs that install components for it, andtoolchain-ab.yml's baseline default.The history lines in those same files still say 1.98.0, deliberately — they are recording what happened, not what is pinned. The pin's own History comment gains this measurement so the next person bumping it can see what bar it had to clear.
One line in
CONTRIBUTING.mdsaid "the pin has moved on to 1.98.0". That is a statement that goes stale at every bump, so it now reads "moved on past it" and stops needing maintenance.Verification
Built and run on 1.98.1: 867 Python tests, 13 core Rust tests,
cargo clippy --workspace --all-targets -D warnings,cargo fmt --check.Independent of #265 (the 0.10.0 release) — disjoint files. If you want 0.10.0's wheels built on 1.98.1, merge this first and I will re-tag.