Repository navigation
fix: bump vergen-git2 to 9.1 so a fresh resolution builds again - #146
Merged
Merged
Conversation
vergen-git2 1.0.7 declares vergen ^9 and vergen-lib ^0.1. The new vergen 9.1.0 depends on vergen-lib 9.1.0, so any resolution that is not pinned by our Cargo.lock (cargo install, cargo-semver-checks in release-plz) pulls two vergen-lib versions into the build script and fails to compile. vergen-git2 9.1.0 is the matching release with the same builder API. Lockfile floor moves from rustc 1.85 to 1.91. Also correct the release-plz.toml comment: the semver check is on.
mrvollger
added a commit
that referenced
this pull request
Sep 18, 2026
Second layer under #146. release-plz still failed to open the 0.13.1 release PR, this time inside `rust-htslib`: ``` error[E0609]: no field `isize` on type `bam1_core_t` error: could not compile `rust-htslib` (lib) due to 10 previous errors ``` ## Cause `hts-sys` 2.2.1 changed bindings that `rust-htslib` 0.46 relies on. Our `Cargo.lock` pins 2.2.0, so locked builds pass. A fresh resolution picks 2.2.1 and fails. This is the same error #127 hit on Read the Docs, so `cargo install fibertools-rs` without `--locked` has been broken since 2.2.1 was published. ## Fix - Pin `hts-sys = "=2.2.0"` as a direct dependency until `rust-htslib` is bumped. The lockfile gains one edge and nothing else changes. - `semver_check = false`. cargo-semver-checks builds the published 0.13.0 baseline the same fresh way, and that crate on crates.io still has `vergen-git2` 1.x, so no change here can make it pass. Neither cargo-semver-checks nor release-plz has a way to honor a lockfile. The comment in `release-plz.toml` explains this. ## Check On stable 1.98.1: a scratch crate that depends on this tree with no lockfile passes `cargo check` (what `cargo install` does), and `cargo build --release --locked` passes with `ft --version` still printing the git commit. Co-authored-by: Mitchell R. Vollger <mvollger@gmail.com>
mrvollger
pushed a commit
that referenced
this pull request
Sep 18, 2026
## 🤖 New release * `fibertools-rs`: 0.13.0 -> 0.13.1 <details><summary><i><b>Changelog</b></i></summary><p> <blockquote> ## [0.13.1](v0.13.0...v0.13.1) - 2026-09-18 ### Fixed - pin hts-sys 2.2.0 and turn off the release-plz semver check ([#148](#148)) - bump vergen-git2 to 9.1 so a fresh resolution builds again ([#146](#146)) - ft call-peaks --haps fills the H1/H2 columns ([#142](#142)) ### Other - put semver_check = false in the [workspace] table ([#150](#150)) - support patch releases from release/** branches ([#143](#143)) </blockquote> </p></details> --- This PR was generated with [release-plz](https://github.com/release-plz/release-plz/). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@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.
release-plz failed to open the 0.13.1 release PR after #143 merged. The
release-plz-prjob died inside cargo-semver-checks:Cause
vergen-git21.0.7 declaresvergen ^9andvergen-lib ^0.1. The newly publishedvergen9.1.0 depends onvergen-lib9.1.0, so a fresh resolution picks it and the build script sees twovergen-libversions. OurCargo.lockpinsvergen9.0.6, which is why local and CI builds still pass. Anything that resolves fresh breaks: cargo-semver-checks in release-plz, andcargo install fibertools-rswithout--locked.Reproduced with a scratch crate holding only our
[build-dependencies]andbuild.rs.Fix
vergen-git29.1.0 is the matching upstream release. The builder API is unchanged, sobuild.rsis untouched. Not 10.x, which needs rustc 1.96.The lockfile floor moves from rustc 1.85 to 1.91 (
cargo-platform0.3.3). Stable is 1.98.The
release-plz.tomlcomment said the semver check was off. It is on, the action installs cargo-semver-checks, and it is what caught this. The comment now says so. Replaces the config toggle in #144 and #145.Check
Full release build passes and
ft --versionstill prints the git commit.