Skip to content

deps: mzdata 0.65.5 to 0.66.6, with the conversion output checked - #83

Merged
RobbinBouwmeester merged 1 commit into
mainfrom
deps/mzdata-0.66
Sep 12, 2026
Merged

RobbinBouwmeester merged 1 commit into
mainfrom
deps/mzdata-0.66

Conversation

@RobbinBouwmeester

Copy link
Copy Markdown
Member

Supersedes #52. Separated from #82 because this bump is not like the others.

Why it warranted its own PR

  • 0.65 → 0.66 is a breaking change for a 0.x crate;
  • it edits the manifest constraint, not only the lock;
  • mzdata parses every mzML the engine reads.

A green cargo test does not cover that last point: no unit test in the workspace opens a real mzML, so compiling was not treated as the answer.

What changed upstream

0.66 splits the crate — mzdata-bindata, mzdata-meta, mzdata-param and mzdata-spectrum are now separate crates — and the digest stack moves with it (digest 0.10→0.11, sha1 0.10→0.11, block-buffer 0.10→0.12, generic-array replaced by hybrid-array). The engine needed no source change.

Checked on real data

20,000 spectra of LFQ_Orbitrap_AIF_Ecoli_02.mzML converted twice: once with a 0.65.5 binary, once with a 0.66.6 binary built from this branch. Same counts (ms1=264 ms2=19736 windows=151) and all four artifacts byte-identical, content hash for content hash:

artifact rows content hash
isolation_windows.parquet 151 993c549d…
ms2_to_ms1.parquet 19,736 9e21dcca…
spectra_ms1.parquet 264 79c63644…
spectra_ms2.parquet 19,736 37a5d2fb…

The parser upgrade changes nothing the engine consumes, which is the only question a bump in this dependency has to answer.

Validation

clippy --all-targets --locked -D warnings, cargo test --workspace --locked (284), cargo audit clean, both generators --check clean. SBOM 174 → 180 components.

Merge #82 first, then this one; the two touch the same lock and SBOM, so the second will want a trivial regeneration which I will do.

🤖 Generated with Claude Code

Supersedes Dependabot #52. Separated from the lock-only bumps because this one is
not like them: 0.65 -> 0.66 is a BREAKING change for a 0.x crate, it edits the
manifest constraint rather than only the lock, and mzdata is the library that
parses every mzML the engine reads. A green `cargo test` does not cover that --
no unit test in the workspace opens a real mzML -- so the compile was not treated
as the answer.

0.66 splits the crate: mzdata-bindata, mzdata-meta, mzdata-param and
mzdata-spectrum are now separate crates, and the digest stack moves with it
(digest 0.10 -> 0.11, sha1 0.10 -> 0.11, block-buffer 0.10 -> 0.12, generic-array
replaced by hybrid-array). The engine needed no source change.

Checked on real data rather than asserted: 20,000 spectra of
LFQ_Orbitrap_AIF_Ecoli_02.mzML converted with a 0.65.5 binary and a 0.66.6 binary
built from this branch. Same counts (ms1=264, ms2=19,736, windows=151) and all
four artifacts byte-identical, content hash for content hash:

  isolation_windows.parquet   993c549d...
  ms2_to_ms1.parquet          9e21dcca...
  spectra_ms1.parquet         79c63644...
  spectra_ms2.parquet         37a5d2fb...

So the parser upgrade changes nothing the engine consumes, which is the only
question a bump in this dependency has to answer.

`sbom.cdx.json` and THIRD_PARTY_LICENSES.md regenerated (174 -> 180 components,
the four new mzdata crates plus the digest-stack changes); both generators
`--check` clean, `cargo audit` clean, clippy `-D warnings` clean, 284 tests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@RobbinBouwmeester
RobbinBouwmeester merged commit 622947d into main Sep 12, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant