chore(release): 0.12.0

[client-software-ci]

0.12.0 (2026-09-28)

BREAKING CHANGES

• TemplateAmountRequirement.name and TemplateAttributeRequirement.name in openjd.model._v1.template are an openjd.expr.FormatString instead of a str; read the template text with .raw() and construct with FormatString(...) (feat!: Bump openjd-* Rust crates to the 0.10.0 release #373) (a2b63c1)

Features

• Bump the openjd-rs crates for their latest fixes: openjd-expr 0.10.0, openjd-model 0.10.0, openjd-sessions 0.7.1 (feat!: Bump openjd-* Rust crates to the 0.10.0 release #373) (a2b63c1)
• Allow format strings in host requirement capability names, with the capability-name constraints checked on the resolved name at job creation (openjd-rs#409)

Bug Fixes

• Report every evaluation error at job creation instead of silently skipping it, so a value-dependent failure such as {{ 10 // Param.N }} with N = 0 fails create_job rather than every session that runs the task (openjd-rs#407)
• resolve parameter type names case-insensitively in reference validation (fix: resolve parameter type names case-insensitively in reference validation #372) (ff0c08c)
• check resolved host requirement capability names at job creation (4d7f9b4)

[github-actions]

This release carries a breaking change to the public v1 Python API, but the changelog gives readers no signal of it.

a2b63c1 is a feat! commit, and the version moves 0.11.14 → 0.12.0 — which under major_on_zero = false is exactly how this repo encodes a breaking change. Yet the generated entry reads only as a dependency bump ("Bump openjd-* Rust crates to the 0.10.0 release"), and there is no ### BREAKING CHANGES section.

What actually broke, per src/openjd/_openjd_rs.pyi in that commit:

• TemplateAmountRequirement.name and TemplateAttributeRequirement.name now return FormatString instead of builtins.str.
• Both constructors now require name: FormatString and reject a bare str.

That is a compile/runtime break for any downstream caller passing or reading name as a str — the commit message itself notes three in-repo tests had to be updated for it. A consumer scanning this changelog to decide whether 0.12.0 is a safe upgrade would conclude it is.

Root cause is likely mechanical: .semantic_release/CHANGELOG.md.j2:4 gates the breaking section on "breaking" in release["elements"], but release["elements"] is keyed by commit type descriptor (features, bug fixes, …), so a feat! lands in features and that branch never fires. python-semantic-release only populates breaking descriptions from a BREAKING CHANGE: footer, which a2b63c1 does not have — the ! marker alone bumped the version without producing any changelog prose.

Two things worth deciding before this ships:

1. Add the breaking-change note to the 0.12.0 section by hand, naming the two name fields and the str → FormatString change.
2. Separately, the template gate looks like dead code. Fixing it (and requiring a BREAKING CHANGE: footer on ! commits) would stop the next breaking release from being silently mislabeled the same way.

[github-actions]

Distinct from the missing-breaking-section point above: this line is the breaking change itself, and it is filed under Bug Fixes.

"Expose the capability name as a FormatString, not a str" is precisely the str → FormatString API break on TemplateAmountRequirement.name / TemplateAttributeRequirement.name. Its own commit message says so: "This is a breaking change to the v1 Python API, and two pre-existing tests prove it." Filing it as a bug fix tells readers the opposite of what it is — a reader doing due diligence on 0.12.0 would take this as a patch-level correction requiring no action on their side.

The cause is the squash: a2b63c1 is a squash-merge of a chore(deps) commit and a fix: commit under a feat! subject, so python-semantic-release emitted one entry per sub-commit and typed each from its own prefix. Note both this line and the Features line point at the same hash a2b63c1, which is the tell.

Worth retyping this entry as the breaking change it is rather than leaving it under Bug Fixes.