chore(release): 0.11.13

[client-software-ci]

0.11.13 (2026-09-16)

Features

• Expose FormatString.segment_count and FormatString.literal_segments on openjd.expr.FormatString (chore(deps): Bump openjd-* Rust crates to 0.8.0 #365)

Bug Fixes

• Bump the openjd-rs crates for their latest fixes: openjd-expr 0.8.0, openjd-model 0.8.0, openjd-sessions 0.6.0 (chore(deps): Bump openjd-* Rust crates to 0.8.0 #365) (1d0cc51)
• Type-check an in/not in item against the list's element type, so 'a' in [1, 2] raises rather than returning False (openjd-rs#396)
• Check resolved-value constraints at template validation, so an over-long interpolated job name or an undeclared parameter in a chunks defaultTaskCount is rejected at decode (openjd-rs#383)
• Accept a single-valued allOf of one literal and one whole-field expression, and re-check the resolved count at job creation (openjd-rs#397)
• Render a NONCONTIGUOUS chunk range as an explicit list to match the v0 reference: [1, 2, 4, 6] is 1,2,4,6 (openjd-rs#398)
• Accept preprocess_job_parameters output as its own input for a LIST[PATH] parameter defaulting to [] (openjd-rs#384)
• Reject an embedded filename of . or .., or one containing a null byte, at template validation (openjd-rs#359)

[github-actions]

This bullet describes only the permissive half of openjd-rs#397. That upstream change has two halves, and the one omitted here is the one most likely to break an existing caller:

A control character in a resolved job name is rejected at create_job; 0.7.1 produced the job.
— 1d0cc51 commit message

So on 0.11.12, create_job(job_template=<name: "render-{{ Param.Suffix }}">, job_parameter_values={"Suffix": "a\nb"}) returned a job named render-a\nb; on 0.11.13 it raises DecodeValidationError. That is exercised by a whole new test class added in #365 (test/openjd/model_v1/test_create_job.py:1637 TestResolvedJobNameControlCharacters), and its docstring calls out the 0.7.1-vs-0.8.0 difference explicitly.

As written, "re-check the resolved count at job creation" only covers the allOf count re-check, so a reader upgrading gets no signal that a previously-accepted create_job call can now fail. Consider splitting it, e.g.:

* Accept a single-valued `allOf` of one literal and one whole-field expression, and re-check the resolved count at job creation (openjd-rs#397)
* Reject a control character in a resolved job name at job creation, where it was previously accepted (openjd-rs#397)

[github-actions]

All seven items are filed under Bug Fixes, but at least four of them reject input that 0.11.12 accepted — they are behaviour-breaking for existing templates and callers, not fixes a consumer can upgrade into blindly:

• 'a' in [1, 2] now raises where it returned False (openjd-rs#396)
• a job name resolving to 129 chars, and a chunks.defaultTaskCount naming an undeclared parameter, are now rejected at decode (openjd-rs#383)
• a control character in a resolved job name is now rejected at create_job (openjd-rs#397)
• embedded filenames ., .., or containing a null byte are now rejected at template validation (openjd-rs#359)

The NONCONTIGUOUS rendering change is also observable to anyone parsing that string: [1, 2, 4, 6] goes from "1,2-6:2" to "1,2,4,6" (openjd-rs#398).

The upstream commit message itself flags this — "openjd-model and openjd-sessions have no public signature changes; the two [breaking] changelog entries are behavioural" — so the breakage is known, it just is not surfaced in the section headings here.

.semantic_release/CHANGELOG.md.j2:4 renders a ### BREAKING CHANGES section, and this file already uses it in 10+ prior releases, so the vocabulary exists. Since these notes are hand-written anyway, consider promoting the input-rejecting items under a ### BREAKING CHANGES heading (or adding a one-line "upgrade notes" preamble). "Behavioural, not signature" breakage is exactly the kind that a downstream pinned to openjd-model-for-python ~= 0.11 will discover in CI rather than in the changelog.