chore(release): bump version to 6.1.5 -- reconcile pyproject.toml/uv.lock with PyPI - #316
Merged
Merged
Conversation
claim_engine_action, update_engine_action_status and get_active_claimed_engine_actions exist in main (8362b1c) and not in the 6.0.18.4 that Resource Explorer resolves from PyPI. Nothing needs writing; the methods need to ship. Recorded with the measured installed-vs-main table and the live evidence that the server side already enforces first-claim-wins arbitration (OMAG-GENERIC-HANDLERS-403-003), so this is a client packaging gap rather than a missing capability -- and with the note that no Kafka consumer is being asked for, since correctness rests on claim rather than delivery. Recovered from an unpushed local commit on main found during a branch/stash audit -- cherry-picked docs-only; left out an unrelated pyproject.toml/ uv.lock version bump (6.1.2 -> 6.1.5) that was bundled into the original commit, since that's the release workflow's job via its own dedicated bump commit, not this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
All three engine-host methods ship in the 6.1.5 wheel. Resource Explorer upgraded 6.0.18.4 -> 6.1.5: 2613 unit tests, 20 live Egeria smoke tests and a live alignment scan all pass, so the minor bump is clean for RE's usage. claim_engine_action exercised against the live platform through the client rather than raw HTTP: claiming an action already IN_PROGRESS under EgeriaWatchdog raises PyegeriaUnauthorizedException carrying OMAG-GENERIC-HANDLERS-403-003. A typed, catchable exception is what an engine-host loop needs to tell 'another host got there first' from a real failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dwolfson04@gmail.com>
…banner main already carries the ISSUE-78 entry (merged as odpi#313 under a different sha), so the only new content on this branch is the note that 6.1.5 resolves it. Kept ours. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dwolfson04@gmail.com>
…trio Log ISSUE-78: engine-host claim trio (resolved by 6.1.5)
…lock with what's already on PyPI PyPI's pyegeria has been at 6.1.5 since 2026-08-26 (published directly, outside this repo's tag-triggered release workflow -- versions 6.1.2 through 6.1.5 were never tagged or given a GitHub Release), while main's pyproject.toml stayed at 6.1.2. This commit only reconciles the version number/lockfile with reality; it ships no code changes -- everything merged to main since the 6.1.5 publish is documentation-only (ISSUE-78, ISSUE-79, a My Profile manual). Follow-up: tag this commit v6.1.5 and create a GitHub Release for it, so the tag history and PyPI finally agree on what shipped where. The release workflow's own 'Publish to PyPI' step is expected to fail on that tag push (PyPI rejects re-uploading an already-published version) -- harmless, but the GitHub Release will need creating manually as a result. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bookkeeping only, no code changes. PyPI's `pyegeria` has been at 6.1.5
since 2026-08-26 15:23 UTC, published directly rather than through this
repo's tag-triggered release workflow — versions 6.1.2 through 6.1.5 were
never tagged or given a GitHub Release, and `main`'s `pyproject.toml`
stayed at 6.1.2 the whole time.
This reconciles the version number and `uv.lock` with what's actually
shipped. Confirmed nothing code-level is missing: every commit merged to
`main` since the 6.1.5 publish is documentation-only (ISSUE-78 #313,
ISSUE-79 #314, the My Profile user manual #312).
Follow-up (not in this PR)
Tag this commit `v6.1.5` and create a GitHub Release for it, so tag
history and PyPI finally agree on what shipped where. The release
workflow's own "Publish to PyPI" step will fail on that tag push (PyPI
rejects re-uploading an already-published version) — expected and
harmless — so the GitHub Release will need creating manually afterward.
🤖 Generated with Claude Code