Skip to content

chore(release): 0.12.0 #353

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
client-software-ci wants to merge 1 commit into from
Closed

chore(release): 0.12.0 #353

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,18 @@
## 0.12.0 (2026-09-04)



### Bug Fixes

@github-actions github-actions Bot Sep 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 0.12.0 section is missing a ### BREAKING CHANGES block, but this release contains one.

b136693 ("Evaluate step-level let bindings in template scope", #341) carries an explicit BREAKING CHANGE: trailer:

create_job() no longer returns a Job carrying evaluated step-level let values. A caller that runs a job whose steps declare a template-scope let referenced from the step's script must switch to create_job_with_symbol_tables and forward the step's step_symbol_tables entry to the session.

That behavior change is real in the head tree — src/openjd/model/_create_job.py:577 documents "The returned Job does not carry the evaluated step-level let values." Yet this release is titled 0.12.0 (a minor bump, not major) and every entry is filed under ### Bug Fixes. A consumer reading only this CHANGELOG has no signal that a previously-working create_job() + run-the-job flow now fails with Undefined variable.

Two things to reconcile:

  1. Add a ### BREAKING CHANGES section for 0.12.0 describing the create_job() step-level let contract change (prior releases such as 0.9.0 and 0.8.0 use that heading).
  2. Confirm the intended version. If the project follows semver strictly, a BREAKING CHANGE: trailer should have produced 1.0.0; if 0.x minor bumps are the convention for breaking changes here, that is fine, but the section heading still needs to be present.

The commit message for #341 says it added a "CHANGELOG breaking-change entry", but git diff b136693^..b136693 -- CHANGELOG.md is empty, so that entry never landed — which is likely why the release tooling did not emit the section.

* coerce LIST[BOOL] items per RFC 0007 §2.15 (#352) ([`105dff2`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/105dff25abc4dfc6970945d881e119438e04fb6c))
* coerce LIST[BOOL] items per RFC 0007 §2.15 ([`105dff2`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/105dff25abc4dfc6970945d881e119438e04fb6c))
* Evaluate step-level let bindings in template scope (#341) ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))
* Evaluate step-level let bindings in template scope ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))
* Record the template-scope let boundary at the merge, and verify it ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))
* Record the let boundary on the de-sugared script too ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))
* Never lower the template-scope let marker ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))
* Stop merging step-level let into the script ([`b136693`](https://github.com/OpenJobDescription/openjd-model-for-python/commit/b1366933e74bea30a98f19496115b200626f22e4))

@github-actions github-actions Bot Sep 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each squashed PR is listed twice, and the internal sub-commits of a squash are leaking into the release notes.

  • Lines 6 and 7 are the same fix (fix: coerce LIST[BOOL] items per RFC 0007 §2.15 #352), once with the PR number and once without — the tooling emitted both the squash-commit subject and its first body line.
  • Lines 8–13 are all the single commit b136693 (fix: Evaluate step-level let bindings in template scope #341). Lines 10–13 ("Record the template-scope let boundary at the merge, and verify it", "Record the let boundary on the de-sugared script too", "Never lower the template-scope let marker", "Stop merging step-level let into the script") are intra-PR review fixups: they describe bugs introduced and then corrected within that same PR, so they never existed in any released version. Publishing them as "Bug Fixes" tells consumers that 0.11.8 shipped a "template-scope let marker" that got lowered, which it never did.

Compare 0.11.8 above (lines 19–23): one hand-written, user-facing line per change. The 0.12.0 block instead has seven raw commit subjects for two actual changes.

Suggest collapsing to one entry per PR, written for a consumer rather than quoting the commit subject: one line for the LIST[BOOL] item coercion and canonical-boolean storage on the created Job (#352), and one line for a step-level let now being evaluated with POSIX path format so a create-time result no longer depends on the creating host (#341).



## 0.11.8 (2026-09-03)


Expand Down
Loading