chore(release): 0.12.0 #360
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,22 @@ | ||
| ## 0.12.0 (2026-08-26) | ||
|
|
||
|
|
||
| ### ⚠ BREAKING CHANGES | ||
| * `extra_let_bindings` is removed from `Session.enter_environment`, `Session.exit_environment` and `Session.run_task` (#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`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
|
|
||
|
|
||
| ### Features | ||
| * accept a resolved symbol table on the v0 session (#357) ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
| * 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`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
| * accept resolved symbol table on v0 session ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
|
There was a problem hiding this comment. 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 |
||
|
|
||
| ### Bug Fixes | ||
| * drain exit step context before failures ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
| * seed the resolved base into wrap hook scope ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
| * replay a wrap env's own base into hook scope ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
| * type the hook-scope capture stand-in exactly ([`457a364`](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/457a364371cb44bf5a6253e612a451e5678621d3)) | ||
|
There was a problem hiding this comment. The 0.12.0 section omits the dependency-floor change that also landed in this range. 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 |
||
|
|
||
|
|
||
| ## 0.11.0 (2026-08-20) | ||
|
|
||
| ### ⚠ BREAKING CHANGES | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_bindingswas a public parameter only onenter_environment:exit_environment(*, identifier, os_env_vars, keep_session_running)— noextra_let_bindingsparameter. It replayed the bindings from the internalself._environment_extra_let_bindingsdict recorded at enter time.run_task(*, step_script, task_parameter_values, os_env_vars, log_task_banner, step_name)— noextra_let_bindingsparameter either. It was added torun_taskand 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.0reading this will go looking forexit_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 toenter_environmentand noting the other two never shipped the parameter in a release.Also in the same bullet: "
step_nameis unchanged on both methods" — three methods are named in the preceding sentence, andexit_environmenthas nostep_nameparameter 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.