chore(release): 0.11.12

[client-software-ci]

0.11.12 (2026-09-14)

Bug Fixes

• deps: Accept a stepEnvironment name reused across steps on the v1 path (fix(deps): Accept a stepEnvironment name reused across steps on the v1 path #363) (d8174e3)
• validate instantiated job models with the template's extension context (fix: validate instantiated job models with the template's extension context #362) (ebac419)
• sessions: Escape strings in the sessions repr output (fix(sessions): Escape strings in the sessions __repr__ output #361) (a3d4f4e)
• sessions: Escape strings in the sessions repr output (a3d4f4e)
• sessions: Address review findings on the repr escaping (a3d4f4e)

[github-actions]

The #361 fix is listed three times in this release section (lines 8, 9, and 10), all pointing at the same commit a3d4f4e.

Lines 9 and 10 are not separate changes — they are the intermediate commits from inside PR #361, which survived into the squash commit's body as * fix(sessions): ... bullets. python-semantic-release parsed those bullets as additional commits, which is why they carry the same a3d4f4e hash and, unlike line 8, no (#361) PR suffix.

Two consequences for a user reading the changelog:

• The same fix looks like three separate fixes in 0.11.12.
• Line 10, Address review findings on the repr escaping, is intra-PR review churn with no standalone user-facing meaning. It describes work that only exists relative to an earlier revision of the same PR, which a released changelog reader cannot see.

Suggest deleting lines 9-10 so only the (#361) entry remains. Since this file is generated, the recurrence is worth addressing at the source too — either disabling squash-commit body parsing in [tool.semantic_release.commit_parser_options], or keeping conventional-commit prefixes out of squash bodies — otherwise any PR merged with a multi-commit body will duplicate the same way in the next release.

[wyongzhi]

Dropped the two squash-body entries in 090b457; #361 now appears once. The source-side fix (disabling squash-commit body parsing, or keeping conventional prefixes out of squash bodies) is out of scope for a release PR — worth a separate issue since any multi-commit PR will duplicate the same way next release.