Skip to content

chore: the RTOS family 0.1.0 -> current - #4

Open
Ttimmahlax wants to merge 1 commit into
mainfrom
chore/primitives-current
Open

Ttimmahlax wants to merge 1 commit into
mainfrom
chore/primitives-current

Conversation

@Ttimmahlax

Copy link
Copy Markdown
Contributor
crate was now
rusty_rtos_core =0.1.0 =0.2.4
rusty_rtos_kernel-core =0.1.0 =0.3.2
rusty_rtos_port-riscv =0.1.0 =0.3.1
rusty_rtos_port-xtensa =0.1.0 =0.3.1

crates/rusty_esp_rtos — the ESP binding onto the Kairos kernel — was pinned to the RTOS family's first release while the family moved through 0.2 and 0.3. Two 0.x majors on three of the four, and in 0.x a minor is a breaking change. This was the widest primitive-to-consumer gap anywhere in the portfolio.

The allocator is deliberately not touched

crates/rusty_esp_alloc holds a floor-guard test asserting VERSION.starts_with("2.0."), with the comment:

the seam exists to hold one pin; if the dependency moves under it, this is where that is noticed rather than in a firmware

Moving that seam needs firmware validation, not a host-test pass. It stays at =2.0.5, and this repo remains held out of the allocator wave — same decision as last time its CI caught that bump.

Verified

cargo check -p rusty_esp_rtos --features port builds against rusty_rtos_core 0.2.4. The xtensa and riscv ports are target-gated and don't build on a host, by design.

🤖 Generated with Claude Code

    rusty_rtos_core          =0.1.0 -> =0.2.4
    rusty_rtos_kernel-core   =0.1.0 -> =0.3.2
    rusty_rtos_port-riscv    =0.1.0 -> =0.3.1
    rusty_rtos_port-xtensa   =0.1.0 -> =0.3.1

crates/rusty_esp_rtos -- the ESP binding onto the Kairos kernel -- was pinned
to the RTOS family's first release while the family moved through 0.2 and 0.3.
Two 0.x majors on three of the four, and in 0.x a minor is a breaking change.
This was the widest primitive-to-consumer gap in the portfolio.

The allocator is deliberately NOT touched here. crates/rusty_esp_alloc holds a
floor-guard test asserting `VERSION.starts_with("2.0.")`, with the comment
"the seam exists to hold one pin; if the dependency moves under it, this is
where that is noticed rather than in a firmware". Moving that seam needs
firmware validation, not a host-test pass, so it stays at =2.0.5 and this
repository is still held out of the allocator wave.

Verified: `cargo check -p rusty_esp_rtos --features port` builds against
rusty_rtos_core 0.2.4. The xtensa and riscv ports are target gated and do not
build on a host by design.

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