Repository navigation
chore: the RTOS family 0.1.0 -> current - #4
Merged
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
rusty_rtos_core=0.1.0=0.2.4rusty_rtos_kernel-core=0.1.0=0.3.2rusty_rtos_port-riscv=0.1.0=0.3.1rusty_rtos_port-xtensa=0.1.0=0.3.1crates/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_allocholds a floor-guard test assertingVERSION.starts_with("2.0."), with the comment: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 portbuilds againstrusty_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