chore: stop Dependabot re-proposing MSRV-breaking mdbook bumps

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.

[prql-bot]

Closing #6203 doesn't stop the bump coming back — Dependabot said so on that thread ("Closing it will not ignore any of these versions in future pull requests"), and the history bears it out: the same mdbook bump has arrived in four consecutive weekly patch-group PRs (#6035, #6062, #6132, #6203) since late June, each failing test-msrv and each closed unmerged. This adds an ignore entry for mdbook-core/mdbook-preprocessor at >= 0.5.3, so the decision recorded on #6203 — stay on 0.5.2 until the MSRV question is settled — actually holds.

The entry is scoped to those two crates rather than the whole patch group, so the rest of the group still flows normally, and the inline comment names the two files to edit when the MSRV is raised so the entry gets removed with it.

Verified: .github/dependabot.yaml parses and the cargo entry resolves to the two ignore rules; prettier reports the file unchanged.

Why 0.5.3 is the boundary

The break is transitive, not in mdbook's own code. From the crates.io sparse index:

mdbook-core 0.5.2: toml ^0.9.8
mdbook-core 0.5.3: toml ^1.1.2
mdbook-core 0.5.4: toml ^1.1.2

toml 1.1.x requires indexmap ^2.13.0, and every indexmap from 2.12 on declares rust-version ≥ 1.82 (2.14.0, which the lock selected on #6203, declares 1.85). indexmap reaches prqlc as a normal dependency via serde_yaml, so it sits in the graph cargo msrv verify checks against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. That's why no pin inside the indexmap ^2.13.0 range restores 1.81 compatibility — the full chain is worked through in the review on #6203.

One correction to that review while I'm here: it implied mdbook-core picked up rust-version = "1.88.0" at 0.5.4. The index shows every 0.5.x release declares 1.88.0, including the 0.5.2 currently in the lockfile — mdbook-prql doesn't set rust-version.workspace = true, so nothing has ever gated it. That's an independent question from this bump and I haven't touched it.

[prql-bot]

Verified the version claims against the crates.io sparse index — mdbook-core 0.5.2 → 0.5.3 does switch toml from ^0.9.8 to ^1.1.2, indexmap 2.12.0 is the first to declare rust-version = "1.82" (2.14.0 declares 1.85), and the lockfile currently sits on indexmap 2.11.4, which declares 1.63. The >= x form in versions: is the syntax GitHub's own docs use, and prettier reports the file unchanged. The scoping to two crates rather than the whole patch group is right, and it matches the decision max-sixty recorded on #6203.

One correction to the rationale comment inline — it's the text a future maintainer reads when deciding whether the entry can go, so worth getting exact.