Skip to content

bump rusty_alloc-api to =2.2.2 - #3

Open
Ttimmahlax wants to merge 1 commit into
mainfrom
chore/rusty_alloc-api-2.2.2
Open

Ttimmahlax wants to merge 1 commit into
mainfrom
chore/rusty_alloc-api-2.2.2

Conversation

@Ttimmahlax

Copy link
Copy Markdown
Collaborator

Follows 2ba0ba0 (=1.1.6) one major on, to the =2.2.2 house standard. Supersedes #2, which bumps the same pin to the now-superseded =2.2.0.

Why this pin matters downstream

It gates the allocator for everything below thoth. The released v0.3.0 tag still carries =0.4.0, so a consumer bumping to it today takes on an allocator two majors stale rather than shedding one — which is exactly what comet hit:

rusty_alloc-api =2.2.2        (house standard)
  ↑ rusty_expressions         =1.1.6 → =2.2.2 in Remade-With-Rust/rusty_expressions#10
  ↑ thoth                     =1.1.6 on main, =0.4.0 on the v0.3.0 tag  ← this PR
  ↑ comet, faucet             pin thoth by tag

The comment was wrong too

The note above the pin claimed to be in step with rusty_expressions "1.1.4" while the pin beside it read =1.1.6. Corrected, and it now records the release constraint rather than just the version.

Ordering: thoth's own build does not depend on rusty_expressions#10

Worth being precise, because the in-step rule reads stricter than it is. rusty_expressions is declared default-features = false, which keeps its optional allocator out of the graph entirely — so thoth builds and tests clean either way, verified both:

rusty_expressions rusty_alloc-api in graph tests
published 0.2.2 (pins =1.1.6) exactly one — v2.2.2 24 pass
=2.2.2 branch via [patch.crates-io] exactly one — v2.2.2 24 pass

What the in-step rule actually protects is a consumer that enables both crates' allocator features — that one would pull two incompatible majors. So the two should still be released together; merging this without releasing rusty_expressions re-opens that hazard, which is why the corrected comment now says so.

The [patch.crates-io] table was verification scaffolding and is not in the diff.

Also worth noting

thoth has no release automation — only portfolio-check.yml, no release-plz — so the tag and publish are manual. Until a tag exists past v0.3.0, comet and faucet cannot pick any of this up.

🤖 Generated with Claude Code

Follows 2ba0ba0 (=1.1.6) one major on, to the =2.2.2 house standard. This pin
gates the allocator for everything downstream of thoth: the released v0.3.0 tag
still carries =0.4.0, so a consumer bumping to it today would take on an
allocator two majors stale rather than shed one.

Also corrects the comment above the pin, which claimed to be in step with
rusty_expressions "1.1.4" while the pin next to it read =1.1.6. rusty_expressions
moves to =2.2.2 alongside this; the two must be RELEASED together, because the
whole point of the in-step pin is that a consumer enabling both crates'
allocators cannot pull two incompatible majors.

thoth's own build does not depend on that ordering -- rusty_expressions is
declared `default-features = false`, which keeps its optional allocator out of
the graph entirely. Verified both ways: against published rusty_expressions
0.2.2 and against the =2.2.2 branch via [patch.crates-io], `cargo tree` shows
exactly one rusty_alloc-api (v2.2.2) in each, and all 24 tests pass under
--all-features.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.

2 participants