lhumina_code/hero_proxy
0
0
Fork 0
Code Issues 8 Pull requests Projects Releases 4 Packages Wiki Activity Actions

Bump hero_proxy workspace to 0.6.0 to cohere with hero_proc + hero_rpc #48

New issue
Closed
opened 2026-05-08 21:21:14 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-08 21:21:14 +00:00
Owner
Copy link

Summary

lhumina_code/hero_proc and lhumina_code/hero_rpc have bumped their workspace versions to 0.6.0 on development, but hero_proxy is still on 0.5.0. Because hero_proxy_sdk declares hero_rpc_derive = "^0.5.0" against branch = "development" (which now resolves to 0.6.0), any downstream Cargo workspace that depends on hero_proxy_sdk AND needs to refresh its hero_proc lock fails to resolve.

Impact

This blocks any downstream consumer the moment they cargo update against fresh upstream. Reproduction in hero_assistance (s47):

  1. hero_proc development was force-pushed; old locked SHA was GC'd.
  2. cargo update -p hero_proc_sdk triggers a re-fetch of all forge git sources.
  3. Cargo re-resolves hero_rpc.git?branch=development → finds version = "0.6.0".
  4. hero_proxy_sdk's hero_rpc_derive = "^0.5.0" fails to match.

Error:

error: failed to select a version for the requirement `hero_rpc_derive = "^0.5.0"`
candidate versions found which didn't match: 0.6.0
location searched: Git repository https://forge.ourworld.tf/lhumina_code/hero_rpc.git?branch=development
required by package `hero_proxy_sdk v0.5.0 (https://forge.ourworld.tf/lhumina_code/hero_proxy.git?branch=development)`

This is not solvable in downstream Cargo.toml alone: [patch.<URL>] rejects same-source same-URL patches, and rev-pinning our direct deps doesn't redirect hero_proxy_sdk's nested branch = "development" declaration.

Request

Bump hero_proxy workspace to 0.6.0 on development so the upstream ecosystem coheres. After the bump, downstream workspaces can do a coordinated 0.5.0 → 0.6.0 lift in a single dedicated commit.

Notes

  • hero_assistance is currently blocked at Phase 27-prep (Forgejo Releases page parity / v0.4.0 milestone) on this dep-graph state. We've filed limitation L-09 in our project documenting this and routed Phase 27-prep to "blocked on upstream."
  • Once hero_proxy is at 0.6.0, downstream projects need to: bump their three version = "0.5.0" workspace pins to "0.6.0", re-run cargo update, and verify the rpc.discover byte-stable invariant survives the hero_rpc#3f50397 recompute-policy change (D-21 in our project).
## Summary `lhumina_code/hero_proc` and `lhumina_code/hero_rpc` have bumped their workspace versions to **0.6.0** on `development`, but `hero_proxy` is still on **0.5.0**. Because `hero_proxy_sdk` declares `hero_rpc_derive = "^0.5.0"` against `branch = "development"` (which now resolves to 0.6.0), any downstream Cargo workspace that depends on `hero_proxy_sdk` AND needs to refresh its `hero_proc` lock fails to resolve. ## Impact This blocks any downstream consumer the moment they `cargo update` against fresh upstream. Reproduction in `hero_assistance` (s47): 1. `hero_proc` `development` was force-pushed; old locked SHA was GC'd. 2. `cargo update -p hero_proc_sdk` triggers a re-fetch of all forge git sources. 3. Cargo re-resolves `hero_rpc.git?branch=development` → finds `version = "0.6.0"`. 4. `hero_proxy_sdk`'s `hero_rpc_derive = "^0.5.0"` fails to match. Error: ``` error: failed to select a version for the requirement `hero_rpc_derive = "^0.5.0"` candidate versions found which didn't match: 0.6.0 location searched: Git repository https://forge.ourworld.tf/lhumina_code/hero_rpc.git?branch=development required by package `hero_proxy_sdk v0.5.0 (https://forge.ourworld.tf/lhumina_code/hero_proxy.git?branch=development)` ``` This is not solvable in downstream `Cargo.toml` alone: `[patch.<URL>]` rejects same-source same-URL patches, and rev-pinning our direct deps doesn't redirect `hero_proxy_sdk`'s nested `branch = "development"` declaration. ## Request Bump `hero_proxy` workspace to `0.6.0` on `development` so the upstream ecosystem coheres. After the bump, downstream workspaces can do a coordinated `0.5.0` → `0.6.0` lift in a single dedicated commit. ## Notes - `hero_assistance` is currently **blocked at Phase 27-prep** (Forgejo Releases page parity / v0.4.0 milestone) on this dep-graph state. We've filed limitation L-09 in our project documenting this and routed Phase 27-prep to "blocked on upstream." - Once `hero_proxy` is at 0.6.0, downstream projects need to: bump their three `version = "0.5.0"` workspace pins to `"0.6.0"`, re-run `cargo update`, and verify the `rpc.discover` byte-stable invariant survives the `hero_rpc#3f50397` recompute-policy change (D-21 in our project).
mik-tf commented 2026-05-09 00:11:08 +00:00
Author
Owner
Copy link

Resolved by f9a252d2 on development (2026-05-09T02:02:47, "fix: bump hero_proxy to v0.6.0, align hero_rpc/hero_proc/herolib_core deps to 0.6.0"). Workspace package + 5 hero_* git deps lifted from 0.5.0 → 0.6.0 — the dep-graph cohere fix this issue requested. PR #49 (which proposed the same bump) closed as superseded.

Follow-on work happens in lhumina_code/hero_assistance per L-09 §Fix plan: one dedicated session lifting hero_assistance to 0.6.0 (4 version pins + cargo update + 279-native baseline re-run with D-21 / D-22 byte-stability attention). No further hero_proxy-side action.

Resolved by `f9a252d2` on `development` (2026-05-09T02:02:47, "fix: bump hero_proxy to v0.6.0, align hero_rpc/hero_proc/herolib_core deps to 0.6.0"). Workspace package + 5 hero_* git deps lifted from 0.5.0 → 0.6.0 — the dep-graph cohere fix this issue requested. PR #49 (which proposed the same bump) closed as superseded. Follow-on work happens in `lhumina_code/hero_assistance` per [L-09 §Fix plan](https://forge.ourworld.tf/lhumina_code/hero_assistance/src/branch/development/limitations/L-09-upstream-dep-graph-blocker.md): one dedicated session lifting hero_assistance to 0.6.0 (4 version pins + `cargo update` + 279-native baseline re-run with D-21 / D-22 byte-stability attention). No further hero_proxy-side action.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
latest
v0.5.0-rc1
v0.5.0
v0.1.1
v0.1.0
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_proxy#48
No description provided.