Skip to content

chore(release): 0.7.6 #233

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

Merged
epmog merged 1 commit into from
Aug 11, 2026
Merged

chore(release): 0.7.6 #233

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
19 changes: 19 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,22 @@
## 0.7.6 (2026-08-11)


### Features
* RFC 0007/0008 support — step-level let bindings, wrap-hook step names, and template-declared
extensions. A step's environments are entered with its step-level EXPR let bindings (RFC 0007),

@github-actions github-actions Bot Aug 11, 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.

This release note states unconditionally that "A step's environments are entered with its step-level EXPR let bindings (RFC 0007)", but at the dependency floor declared in pyproject.toml that isn't true.

src/openjd/cli/_run/_local_session/_session_manager.py:443 reads the bindings defensively:

# getattr guard: requires an openjd-model with Step.let on the
# instantiated Job (openjd-model PR #318+); collapse to plain
# `step.let` once the version pin floor guarantees it.
step_let_bindings = getattr(step, "let", None)

but pyproject.toml pins openjd-model >= 0.9,< 0.12. On any resolved openjd-model older than the release that added Step.let, getattr returns None, so extra_let_bindings is never forwarded and step-level let silently no-ops — environment variables and actions that reference those bindings will fail to resolve (or resolve to nothing) with no error explaining why. A user installing openjd-cli==0.7.6 with an older-but-permitted openjd-model gets a release that advertises the feature and doesn't have it.

Note the sibling openjd-sessions floor was raised to >= 0.10.11 in this same release precisely to remove an equivalent version-skew guard; the openjd-model floor appears to have been left behind. Suggest either raising the openjd-model lower bound to the first version with Step.let (and dropping the getattr for a plain step.let), or qualifying this changelog bullet so the requirement is visible to users.

so environment variables and actions can reference them; RFC 0008 wrap hooks now resolve
`WrappedStep.Name`; only the extensions a template declares are enabled; and `Job.Name` is
seeded into the symbol table. ([`962e359`](https://github.com/OpenJobDescription/openjd-cli/commit/962e359b8c2aea7a3b818f6103a3fe6bb84177c4))
* Support RFC extensions in environment templates (#213) ([`cc8d354`](https://github.com/OpenJobDescription/openjd-cli/commit/cc8d3543c31e74d23897995127d3075bf314782d))

### Bug Fixes
* Require `openjd-sessions >= 0.10.11` ([`dfa118d`](https://github.com/OpenJobDescription/openjd-cli/commit/dfa118de0f7a49dee568e4c74f90d42faf6f8dd7))
* `openjd run` printed a stack trace instead of a readable error message when an environment failed to enter (e.g. violating RFC 0008's "at most one wrap environment" rule)
* `openjd run` reported a misleading "Must exit Environment X first" error when an environment failed partway through entering (e.g. a bad environment `variables` expression)
* `Step.Name` was not available in a step's `let` bindings and step-environment actions (RFC 0007 EXPR)
* Defer adaptive chunk adjustment without a measurable sample (#232) ([`7091007`](https://github.com/OpenJobDescription/openjd-cli/commit/7091007439699ba51549e36e94873bf689eb7bd9))


## 0.7.5 (2026-02-09)


Expand Down
Loading