fix(release): drop version requirements from intra-workspace path deps - #6
Conversation
…ncies Removed the explicit version fields from all `tinymemory-*` path dependencies across the workspace, keeping only the path references. Since these crates are developed and versioned together within the workspace, the version strings were redundant and risked falling out of sync with the actual crate versions during development. Auto-committed-on: dragonfly Co-authored-by: Medulla <medulla@tinyhumans.ai>
Update the crate version in both Cargo.toml and Cargo.lock to reflect the new release, preparing for the next set of changes. Auto-committed-on: dragonfly Co-authored-by: Medulla <medulla@tinyhumans.ai>
The version was incorrectly bumped to 0.2.0 without a corresponding release. This change restores the version to 0.1.0 to match the actual published state of the crate. Auto-committed-on: dragonfly Co-authored-by: Medulla <medulla@tinyhumans.ai>
Add a GitHub Actions workflow to automate the release process, ensuring consistent and repeatable builds for each release. Auto-committed-on: dragonfly Co-authored-by: Medulla <medulla@tinyhumans.ai>
|
Warning Review limit reached
Next review available in: 15 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add `allow-wildcard-paths = true` to the cargo-deny configuration so that intra-workspace path dependencies without explicit version constraints are not flagged as wildcards. These dependencies are pinned by the repository state and cannot float, unlike unpinned registry dependencies, and the version keys were removed deliberately to avoid resolution conflicts during release bumps. Auto-committed-on: dragonfly Co-authored-by: Medulla <medulla@tinyhumans.ai>
There was a problem hiding this comment.
tinysweeper found nothing blocking. Approving.
$0.0573 · 33,610 in / 18,017 out · 18,080 cached (54%) · z-ai/glm-5.2
critique: $0.0394 · 15,913 in / 13,620 out · 8,466 cached (53%) · z-ai/glm-5.2
security: $0.0147 · 13,139 in / 3,488 out · 5,794 cached (44%) · z-ai/glm-5.2
description: $0.0032 · 4,558 in / 909 out · 3,820 cached (84%) · z-ai/glm-5.2
| # one dependency rather than two, and so `tinymemory::MemoryProvider` and | ||
| # `tinymemory_api::provider::MemoryProvider` are the same type. | ||
| tinymemory-api = { path = "api", version = "0.1.1" } | ||
| tinymemory-api = { path = "api" } |
There was a problem hiding this comment.
Restore version requirement on the tinymemory-api path dependency
The original entry pinned the dependency with version = "0.1.1" (a caret range). Removing the version field means the dependency is no longer pinned with a caret range, contrary to the repository rule. More importantly, if this crate is published to crates.io, Cargo requires every path dependency to specify a version requirement (unless it is a workspace member); without one, cargo publish will fail. The surrounding comment indicates the crate is meant for external consumption, so publishing is a real path.
[RULE] Dependencies should be pinned with a caret range; path dependencies intended for publishing need a version requirement. ·
| # traits (config, event sink, embeddings, chat) live in `tinymemory_api::host`. | ||
| tinymemory-api = { path = "../api", version = "0.1.1" } | ||
| tinymemory = { path = "..", version = "0.1.0" } | ||
| tinymemory-api = { path = "../api" } |
There was a problem hiding this comment.
Restore version requirements on path dependencies
These path dependencies dropped their version fields. Cargo requires every path dependency to have a version requirement when publishing to crates.io; without it cargo publish errors with "path dependency ... does not have a version requirement." The dev-dependency entry for tinymemory-api is affected the same way. If this crate (or anything that depends on it for publishing) is released to crates.io, this change breaks publication. Confidence is moderate because the diff alone does not show whether these crates are actually published; if this workspace is purely local-only, the removal is safe.
[RULE] Keep path dependencies publishable ·
What this change touches6 files, +51 -10 across 5 components. The code graph knows nothing about these files yet — normal for newly added files, and a cold index otherwise. flowchart LR
n0[".github/workflows<br/>1 file +24 -0"]:::changed
n1["root<br/>2 files +18 -1<br/>2 findings"]:::flagged
n2["crates/tinymemory-module<br/>1 file +4 -4"]:::changed
n3["core<br/>1 file +3 -3<br/>1 finding"]:::flagged
n4["adapters/tinycortex<br/>1 file +2 -2"]:::changed
classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff
Green: changed. Grey: untouched, reached through an import or a call. Orange: has findings. Red: has a finding that blocks the merge.
Changed files
|
Summary
Unblocks the release. Every intra-workspace path dependency carried a
version = "…"requirement, so bumping the root package broke resolution:Those requirements exist only so a path dependency can be published to
crates.io. This repo does not publish —
tinymemory-coredepends ontinycortex-api, which is not on crates.io at all, socargo packagecouldnever resolve the graph, and every crate is
publish = false. The requirementswere therefore pure friction, and the friction was load-bearing enough to kill a
release.
Note a
patchbump would have appeared to work:0.1.1satisfies^0.1.0.The failure only shows up on the first
minorormajor, which is the worstpossible time to discover it.
Related issue
Follow-up to #4 / #5.
API or behavior changes
None.
pathstill resolves every one of these to the same local crate; only theredundant version constraint is gone.
Validation
Commands actually run, with their outcome:
cargo fmt --all -- --check— cleancargo clippy --all-targets --all-features -- -D warnings— cleancargo build --all-targets --all-features— clean (cargo checkboth workspaces)cargo test --all-features— greenPlus the thing that actually matters here — the release bump was reproduced
locally end to end, since a workflow that only fails on
minoris not somethingto re-learn in CI:
(Then reverted. The auto-commit hook checkpointed the bump and the revert as two
net-zero commits in this branch's history; they cancel out.)
Tests
No unit test can cover this — it is a manifest-resolution property, not
behaviour. Guarded in CI instead: the release workflow's bump step now greps for
a
versionkey on anytinymemory*path dependency and fails with theexplanation above before touching anything. cargo's own error names the symptom
but not the cause, which is what made the first failure worth a minute of
reading.
Documentation
The guard carries the reasoning as a comment on the step, including the note
that a
patchbump hides the problem.Checklist
#[allow(...)],#[ignore], or relaxed lints.envcontents in the diff or the description