chore: release

[ariel-os-releaze-plz]

🤖 New release

• sbd-gen-schema: 0.3.0 -> 0.4.0 (⚠ API breaking changes)
• sbd-gen: 0.3.0 -> 0.3.1

⚠ sbd-gen-schema breaking changes

--- failure constructible_struct_adds_field: externally-constructible struct adds field ---

Description:
A pub struct constructible with a struct literal has a new pub field. Existing struct literals must be updated to include the new field.
        ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/constructible_struct_adds_field.ron

Failed in:
  field Uart.possible_peripherals in /tmp/.tmpH7PsnJ/sbd/crates/sbd-gen-schema/src/lib.rs:222
  field Uart.host_facing in /tmp/.tmpH7PsnJ/sbd/crates/sbd-gen-schema/src/lib.rs:231

Changelog

sbd-gen-schema

0.4.0 - 2026-04-08

Added

• make schema version separate from schema crate version

Other

• (deps) bump semver from 1.0.27 to 1.0.28
• (uart) equate absent and empty .possible_peripherals
• Generate code for UARTs
• Add property for UART MCU peripherals
• Expose presence of host facing UARTs as has_host_facing_uart
• Define host_facing UART property

sbd-gen

0.3.1 - 2026-04-08

Other

• (deps) bump insta from 1.47.1 to 1.47.2
• (deps) bump insta from 1.47.0 to 1.47.1
• (deps) bump insta from 1.46.3 to 1.47.0
• (uart) equate absent and empty .possible_peripherals
• Test code generation
• Generate code for UARTs
• Expose presence of host facing UARTs as has_host_facing_uart
• address clippy lint

---

This PR was generated with release-plz.

[kaspar030]

hm, I'd like some more control over the breaking/non-breaking here. :/

Technically this is not a breaking schema change (only some new fields added, should be backwards compatible), but it is a breaking schema crate api change. So the version bumps where chosen correctly. It is just that the schema crate now is at 0.4.0, which makes it a breaking change, 0.3.x files are not accepted anymore.

Not sure if we want to introduce another version number so we can have separate schema crate and schema file format versions. Maybe that is the easiest - but we'd have to manually manage it.

[kaspar030]

Technically this is not a breaking schema change (only some new fields added, should be backwards compatible), but it is a breaking schema crate api change. So the version bumps where chosen correctly. It is just that the schema crate now is at 0.4.0, which makes it a breaking change, 0.3.x files are not accepted anymore.

Not sure if we want to introduce another version number so we can have separate schema crate and schema file format versions. Maybe that is the easiest - but we'd have to manually manage it.

Now those are decoupled, we should look into a CI check that ensures a schema (not crate) version breaking change translates into a sbd-gen breaking change.

[kaspar030]

I think this can be merged.

[ROMemories]

Otherwise looks fine, but it would seem like less magic is going on with an actual constant for the schema version.

[ROMemories]

After some out-of-band discussion, I still think the schema version should be a constant, but for velocity reasons I'm approving the release.