chore(release): 0.12.0

[client-software-ci]

0.12.0 (2026-08-26)

⚠ BREAKING CHANGES

• extra_let_bindings is removed from Session.enter_environment, Session.exit_environment and Session.run_task (feat: accept a resolved symbol table on the v0 session #357). The parameter was public in 0.11.0. Callers must deliver step-scope EXPR let values through the new resolved_symtab parameter — the resolved symbol table the service already produces per step and per environment — instead. step_name is unchanged on both methods. (457a364)

Features

• accept a resolved symbol table on the v0 session (feat: accept a resolved symbol table on the v0 session #357) (457a364)
• deliver step-scope let bindings to run_task — added extra_let_bindings to run_task, then superseded within this same release; see BREAKING CHANGES above (457a364)
• accept resolved symbol table on v0 session (457a364)

Bug Fixes

• drain exit step context before failures (457a364)
• seed the resolved base into wrap hook scope (457a364)
• replay a wrap env's own base into hook scope (457a364)
• type the hook-scope capture stand-in exactly (457a364)

---

Manual edits on top of the generated changelog

Two docs: commits were added to this branch. The generated section is unchanged apart from what is listed here.

1. Added the ⚠ BREAKING CHANGES section (9989be5). The generated output listed this release only under Features and Bug Fixes, so a reader upgrading from 0.11.x had nothing telling them a public parameter had disappeared. The section styling matches the existing 0.11.0 entry in CHANGELOG.md.

2. Annotated the run_task feature entry (same commit). Read on its own, "deliver step-scope let bindings to run_task" advertises extra_let_bindings on run_task — a parameter that does not exist in 0.12.0, because it was added and removed inside this same release. The annotation points at the breaking section instead.

3. Lower-cased one entry (93ec579). "Accept resolved symbol table on v0 session" was the only entry in the 0.12.0 block not opening lower-case, inherited from its source commit subject. Capitalized entries in older released sections were deliberately left alone.

Both commits are typed docs:, which is outside this repo's patch_tags, so neither can perturb a future version calculation however this branch lands.

Why the breaking section was not generated

The Jinja template does render one, from release["elements"]["breaking"]. The BREAKING CHANGE: footer for this release sits on a chore: commit (f05bf28), and no chore entries reach the rendered output at all — the template iterates only breaking, features, bug fixes and performance. That is the likely cause; I have not re-rendered to confirm it. If we want this to self-generate next time, the footer needs to ride a feat: or fix: commit.

Two related notes for whoever runs the release:

• The footer was missing from feat: accept a resolved symbol table on the v0 session #357's squash commit (457a364) in the first place, which is why the removal was originally queued to ship as 0.11.1. chore: raise the openjd-model floor to 0.11.6 #358 supplied it.
• Also note the ⚠ prefix used here matches the hand-written 0.11.0 entry, not the template's plain ### BREAKING CHANGES. The two styles are inconsistent in CHANGELOG.md today.

[godobyte]

super nit - inconsistent casing.

[github-actions]

The breaking-change scope is inaccurate for two of the three methods named here.

Checking the 0.11.0 tree (396b3c1:src/openjd/sessions/_session.py), extra_let_bindings was a public parameter only on enter_environment:

• exit_environment(*, identifier, os_env_vars, keep_session_running) — no extra_let_bindings parameter. It replayed the bindings from the internal self._environment_extra_let_bindings dict recorded at enter time.
• run_task(*, step_script, task_parameter_values, os_env_vars, log_task_banner, step_name) — no extra_let_bindings parameter either. It was added to run_task and then removed within 0.12.0, which the Features bullet below already says.

So "The parameter was public in 0.11.0" is only true for enter_environment. As written, a caller pinned to ~=0.11.0 reading this will go looking for exit_environment(extra_let_bindings=...) / run_task(extra_let_bindings=...) call sites that never existed, and may conclude the release is more disruptive than it is. Suggest scoping the sentence to enter_environment and noting the other two never shipped the parameter in a release.

Also in the same bullet: "step_name is unchanged on both methods" — three methods are named in the preceding sentence, and exit_environment has no step_name parameter at all (it recovers the name from _environment_step_names, _session.py:1120). Worth naming the two methods that do take it (enter_environment, run_task) explicitly.

[github-actions]

Duplicate entry: line 9 ("accept a resolved symbol table on the v0 session (#357)") and this line ("accept resolved symbol table on v0 session") are the same change, same commit 457a364, differing only in wording. One of the two should be dropped.

[github-actions]

The 0.12.0 section omits the dependency-floor change that also landed in this range. f05bf28 raised openjd-model from >= 0.11.4,< 0.12 to >= 0.11.6,< 0.12 (pyproject.toml:44).

That is the kind of change an integrator needs from a changelog — it can force a resolver change or conflict with a pin elsewhere in their dependency set — and it is not derivable from any of the bullets currently listed. Worth a line under Features or a Dependencies/Miscellaneous heading, e.g. "raise the openjd-model floor to 0.11.6 (first release accepting an environment defining only onExit)".