release: v0.4.0

release: v0.4.0rc2

release: v0.4.0rc1

feat(changelog): order by PEP 440 and drop --generate-notes (omnigent…

…-ai#1841)

Two fixes surfaced from a v0.4.0dev0 tag push:

1. github-release.yml failed with HTTP 422 "body is too long (maximum is
   125000 characters)": --generate-notes asked GitHub to list every PR since
   the previous tag (193 for the v0.3.0→HEAD range), overflowing the release-
   body cap. We draft our own curated notes in draft-release-notes.yml, so
   --generate-notes is dead weight. Replace it with a short placeholder body
   that draft-release-notes.yml overwrites; the 422 failure mode is gone.

2. A manual run for a dev tag (v0.4.0dev0 --base v0.3.0) harvested 6 PRs but
   reported "CHANGELOG.md already up to date" — generate.py gated the write on
   a strict ^v\d+\.\d+\.\d+$ regex that a .dev0 tag fails, so it silently
   skipped the write. Order CHANGELOG.md by PEP 440 (packaging.Version) using
   the full tag string as the block header, so dev/rc tags land in their own
   correctly-ordered blocks (v0.4.0 > v0.4.0rc1 > v0.4.0.dev0 > v0.3.0) and
   coexist with the eventual final rather than collapsing into it. Re-running a
   tag still replaces its own block (idempotent).

previous_final_tag stays finals-only (a real v0.4.0 still diffs against v0.3.0,
not an intervening rc). The workflow_run auto-trigger is unchanged and remains
finals-only — dev/rc changelog blocks are reachable only by manual dispatch.
The harvest step installs packaging (it runs bare python3 before uv sync), and
the dry_run input description is trimmed.

87 tests pass; verified end-to-end that v0.4.0dev0 --base v0.3.0 now writes a
correctly-ordered block instead of no-op'ing.

Co-authored-by: Isaac

release: v0.3.0

release: v0.3.0rc1

release: v0.2.0

Drop the rc suffix — promote the validated 0.2.0rc1 to the final 0.2.0 across
the three lockstep packages (versions + cross-pins + uv.lock).

Co-authored-by: Isaac

release: v0.2.0rc1

Bump the three lockstep packages (and their cross-pins + uv.lock) to the
0.2.0rc1 release candidate. Cut on release/v0.2.0; the final v0.2.0 will be
tagged on this same branch.

Co-authored-by: Isaac

release: v0.1.1

fix(oss): add READMEs to the SDK packages so twine check --strict pas…

…ses (omnigent-ai#201)

The secure-release pipeline runs `twine check --strict`, which failed
omnigent-client and omnigent-ui-sdk with "long_description missing" — the
core omnigent package sets readme = "README.md" but the two SDKs never
did. Add a README to each SDK and point `readme` at it (also gives them a
rendered PyPI page). Verified: twine check --strict PASSES for all four
SDK distributions.

Co-authored-by: Isaac
(cherry picked from commit b049d3a)