Skip to content

fix(release): zypi --version and ACP agentInfo show the release version (plan decision 16) - #17

Merged
zy1233 merged 1 commit into
mainfrom
fix/release-version-numbers
Oct 12, 2026
Merged

zy1233 merged 1 commit into
mainfrom
fix/release-version-numbers

Conversation

@zy1233

@zy1233 zy1233 commented Oct 12, 2026 •

Copy link
Copy Markdown
Owner

Summary

zypi --version printed 1.0.8, the version of the upstream project. The ACP agentInfo.version was fixed at 0.1.0. Neither told a user which release they had. This PR makes both show the release version. This is plan decision 16, option (a): no stamp from the workflow.

Stacked on #15, which is merged first (59545c1); this branch is then rebased onto main and its base moved there. The CHANGELOG hunks need the [0.5.0] section that #15 creates.

What changes

  • pi-pager-bin and pi-version (the Cargo.toml files and their two entries in tui/Cargo.lock): 1.0.8 -> 0.5.0, the version of pi-agent-cli-lc. zypi --version prints 0.5.0 (<commit>).
  • pi_agent_cli/agent.py: agentInfo.version reads the version of the installed pi-agent-cli-lc. A checkout that was never installed has no package metadata and gets 0.0.0+unknown, which is still a valid version.
  • CHANGELOG.md: a new Changed entry (with the behaviour change below), and the known issue "Version numbers" is removed.
  • docs/AUDIT/AUDIT-PHASE6-PHASE7-2026-09-30.md, row 14: said that _AGENT_INFO is hard-coded and was left alone. It now says that this changed later.

pi-pager and pi-shell also have version 1.0.8. Decision 16 does not cover them, so they stay.

Behaviour change

The version number is lower than before. pi-config applies a [[version_overrides]] patch only when the installed version is inside the range of the patch. A patch with a minimum_version above 0.5.0 no longer applies. No patch like that ships with zypi. A user may have written one in a config file, and nobody can find out. Auto-update is off (bg_update_rx = None), so the version checks of pi-update are not reached.

Why the workflow does not set GROK_VERSION

pi_version::IS_DEV_BUILD is option_env!("GROK_VERSION").is_none(), and pi-workspace reads the same variable in folder_trust_inert(). A build that has the variable is a release build: folder trust is on (it prompts, and it gates repo-local .envrc, hooks, plugins, MCP and LSP), and the dev_build telemetry field changes. v0.3.0 and v0.4.0 were built without the variable, so folder trust is off in every zypi release so far. To turn it on is a change of behaviour that needs its own decision. So the version must come from Cargo.toml, and a test now fails if a workflow sets the variable.

Tests

  • packages/pi-agent-cli/tests/test_agent_info.py: initialize reports the installed version; the fallback is a valid version.
  • scripts/tests/test_release_versions.py: the two crates and Cargo.lock equal the version of pi-agent-cli-lc (the message says what to change); no workflow sets GROK_VERSION.

Mutation checks (each change was applied alone, the tests failed, the file was restored): agent version written into the source again; fallback not a valid version; wrong distribution name; pi-version off by one patch; pi-pager-bin back to 1.0.8; each of the two Cargo.lock entries not updated; a workflow that sets GROK_VERSION. All 8 were caught.

Checks that ran

  • Windows (local): ruff check . and ruff format --check . pass. Full pytest: 2,516 passed, 39 skipped, 31 deselected (real_llm), 299 s. The 6 new tests are in that number. The new tests failed on the old code (5 failed; the GROK_VERSION guard passed, because no workflow sets it today).
  • CI (run 38230414753): Ruff passes. pytest on Python 3.11, 3.12 and 3.13 on Linux: 2,516 passed, 39 skipped, 31 deselected each. These are the Windows numbers, so the new tests pass on Linux too.
  • TUI CI (run 38230414764): Gates + cargo check 2 m 46 s (dependency graph 980 packages, which is the ceiling). cargo test 14 m 03 s: 8,665 passed, 0 failed, 22 ignored, with PI_E2E_REQUIRED=1 (the end-to-end tests talk to the real Python agent). These are the numbers of main at 4fc028a. So the manifest and lock edits build, and the Rust tests did not change.
  • Both runs are on the commit as first pushed (b7567dd). The branch was then rebased onto main after docs(release): fold [Unreleased] into [0.5.0], add the missing entries and the macOS binary #15's squash. The tree of the rebased commit (cb9a9b7) is the tree of b7567dd (git diff b7567dd cb9a9b7 is empty), so those results stand.

Not verified

  • Nobody has seen the output of zypi --version. No test checks it. I did not run a binary when I wrote this. The CI shows that the workspace builds and that the tests pass, not what the binary prints. From the code, it prints 0.5.0 (<12-character commit>). The first release build that is made after this PR shows it.
  • The guard test for GROK_VERSION was not asked for. It protects the choice of option (a). Drop test_no_workflow_sets_grok_version if it is more than you want.

zy1233 added a commit that referenced this pull request Oct 12, 2026
…entry in #15, condition 4 skipped)

After the first push of this PR the owner answered three questions:

- Decision 16 is done now, in its own PR (#17, stacked on #15): the plan item
  moves from "decided, not done" to "done", the known issue about the version
  numbers leaves the list (it comes back only if #17 is not merged before the
  tag), and the "not verified" text now says what the CI of #17 proved and
  what nobody has seen (the output of `zypi --version`).
- The macOS arm64 binary entry went into #15 (CHANGELOG, README and
  docs/TUI-AND-CODE-AGENT.md, "built by CI, nobody has started it"): condition 5
  says so, with the new entry counts (20 new entries; the release body is
  45,076 B, and 45,855 B after #17).
- Condition 4 (compare with v0.4.0) is skipped. V0.5 does not wait for it.

The execution log gets a "续 2" part in section 10.15 with the answers, what
changed, the tests (6 new, 8 mutations caught), the Windows and Linux numbers
and the CI runs of #17. The index, the revision log and the link definitions
follow. Only documents change.
@zy1233
zy1233 changed the base branch from docs/changelog-0.5.0 to main October 12, 2026 09:59
zy1233 added a commit that referenced this pull request Oct 12, 2026
…s and the macOS binary (#15)

## Summary

The release page of a tag shows only the `CHANGELOG.md` section that has the version of the tag (`release.yml` extracts it with `awk`). Today that section, `[0.5.0]`, has nothing about the work in `tui/`, and `[Unreleased]` has most of it. This PR makes `[0.5.0]` the text of the release. It is exit condition 5 of the V0.5 milestone ([v0.5.0](https://github.com/zy1233/pi-python/milestone/1)).

Three files change: `CHANGELOG.md`, and, for the macOS binary, `README.md` and `docs/TUI-AND-CODE-AGENT.md`. The `CHANGELOG.md` diff is larger than the new text, because the moved bullets show as removed and added.

- **Fold.** The 18 bullets of `[Unreleased]` (9 Added, 5 Changed, 4 Fixed) move into the matching groups of `[0.5.0]`, after the bullets that are already there. `[Unreleased]` is empty. The date of `[0.5.0]` is 2026-10-12.
- **A summary paragraph** at the top of `[0.5.0]`: what the release is.
- **20 new bullets** for things that were in neither section:

| Group | New entries |
|---|---|
| Added | `/model` through ACP session config options; **a prebuilt `zypi` for macOS on Apple silicon** |
| Changed | `zypi -p` refuses a sandbox and names the flags it ignores; `zypi` is the product name where a name is shown |
| Removed (new group) | the Rust agent runtime (with the numbers); the screens, commands and flags that went with it |
| Fixed | a tool left running after quit; `session/close` and `session/resume`; the title and time in `session/list`; `AGENTS.md` read twice on macOS; the `ssh-wrap` alias; messages that name things that do not exist |
| Known issues (new group) | 8 items, from the list in the plan |

- **The macOS binary** (the second commit; you chose this after the dry run in #14 passed). The Added entry, the Known issue "tested on Linux only", the install steps in the TUI guide, the platform table, the download paragraph of the README and its roadmap line say that `zypi-macos-arm64` exists, that CI builds it, and that nobody has started it.

## Where the facts come from

- **2,500 to 1,755 `.rs` files, 1,620,612 to 1,021,067 lines** under `tui/crates`: `git grep -c -e "^"` at `v0.4.0` and at `main` (`4fc028a`).
- **1,311 to 1,257 packages**: the `[[package]]` entries of `tui/Cargo.lock` at the same two revisions.
- **470,461,776 to 420,767,096 bytes** (−10.6 %): the `release_baseline` run [38221952524](https://github.com/zy1233/pi-python/actions/runs/38221952524) on `4fc028a`. The same run builds in 1,195 s (v0.4.0: 1,647 s) and `--version` takes 23.4 ms.
- **Removed flags** `--fork-session`, `--leader`, `--no-leader` and `--leader-socket`: I compared the long flags of `PagerArgs` (`pi-pager/src/app/cli.rs`) at `v0.4.0` and `main`. 7 flags were removed and none was added. The other 3 are the `--local-workspace*` flags, which a release build never had, so they are not in the entry.
- **The macOS binary**: the dry run [38223353755](https://github.com/zy1233/pi-python/actions/runs/38223353755) (from the branch of #14) built `zypi-macos-arm64` on `macos-14` in 25 min. `release.yml` has no signing or notarization step.
- **The other entries** come from the code and from sections 10.2, 10.7, 10.8 and 10.10 of `docs/PLAN/archive/PLAN-RUST-AGENT-RUNTIME-REMOVAL-EXECUTION-LOG.md`. I read the code again for `-p` (`print_mode.rs`), the `session/list` title (`session_list.py`), the `AGENTS.md` check (`context_files.py`) and the `session/close` flag (`__main__.py`).

## Decisions for you

1. **The date.** It is 2026-10-12 (today). If you tag on another day, change it before the tag.
2. **Known issues in the release text.** The release page will show the 8 items. They are true as far as I know, but they are your public statement. Cut any you do not want to publish. One of them (`Version numbers`) goes away with #17 (plan decision 16). #17 is stacked on this PR and merges right after it.

## Not verified

- How GitHub shows the text. I ran the `awk` program of `release.yml` (Git for Windows `awk`) on this file: the body is 44 KB, has the 5 groups, and has no `## [` line.
- The version claim in Known issues (`zypi --version` shows `1.0.8`) comes from the code (`build.rs`, `Cargo.toml`). I did not run a release binary when I wrote this.
- Nobody has run the macOS binary. The advice about `xattr -d com.apple.quarantine` is general macOS behaviour. I did not test it.
- No person other than me has read the new English text.

## Verification

- Bullet lines before: 75. After: 95. The difference is the 20 new bullets. No bullet was lost or changed except the Known issue "tested on Linux only", which has one more sentence. The text from `## [0.4.0]` on is the same.
- Every backtick and `**` pair in `CHANGELOG.md` is balanced.
- `ruff check .` and `ruff format --check .`: clean (nothing in Python changes).
…on (plan decision 16)

`zypi --version` printed 1.0.8, the version of the upstream project, and the ACP
`agentInfo.version` was fixed at 0.1.0 in agent.py. Neither told a user which
release they had.

- The `pi-pager-bin` and `pi-version` crates, and their entries in tui/Cargo.lock,
  carry 0.5.0, the version of `pi-agent-cli-lc`. `zypi --version` prints
  `0.5.0 (<commit>)`. `pi-pager` and `pi-shell` keep 1.0.8: plan decision 16 does
  not cover them.
- `agentInfo.version` reads the version of the installed `pi-agent-cli-lc`. A
  checkout that was never installed has no package metadata and gets
  `0.0.0+unknown`, which is still a valid version.
- Tests: the agent reports the installed version; the two crates and Cargo.lock
  stay equal to the version of `pi-agent-cli-lc`; no workflow sets GROK_VERSION
  (that variable also marks a build as a release build, which turns the
  folder-trust prompt on).
- CHANGELOG: a new Changed entry (with the behaviour change for a
  `[[version_overrides]]` patch above 0.5.0) and the "Version numbers" known issue
  is removed. The audit note that said `_AGENT_INFO` is hard-coded now says it
  changed later.

Not run here: cargo build and cargo test, and `zypi --version` (WSL does not start
on this machine). TUI CI builds the workspace and runs the Rust tests.
@zy1233
zy1233 force-pushed the fix/release-version-numbers branch from b7567dd to cb9a9b7 Compare October 12, 2026 10:00
@zy1233
zy1233 merged commit d57fd9b into main Oct 12, 2026
7 checks passed
@zy1233
zy1233 deleted the fix/release-version-numbers branch October 12, 2026 10:02
zy1233 added a commit that referenced this pull request Oct 12, 2026
…entry in #15, condition 4 skipped)

After the first push of this PR the owner answered three questions:

- Decision 16 is done now, in its own PR (#17, stacked on #15): the plan item
  moves from "decided, not done" to "done", the known issue about the version
  numbers leaves the list (it comes back only if #17 is not merged before the
  tag), and the "not verified" text now says what the CI of #17 proved and
  what nobody has seen (the output of `zypi --version`).
- The macOS arm64 binary entry went into #15 (CHANGELOG, README and
  docs/TUI-AND-CODE-AGENT.md, "built by CI, nobody has started it"): condition 5
  says so, with the new entry counts (20 new entries; the release body is
  45,076 B, and 45,855 B after #17).
- Condition 4 (compare with v0.4.0) is skipped. V0.5 does not wait for it.

The execution log gets a "续 2" part in section 10.15 with the answers, what
changed, the tests (6 new, 8 mutations caught), the Windows and Linux numbers
and the CI runs of #17. The index, the revision log and the link definitions
follow. Only documents change.
zy1233 added a commit that referenced this pull request Oct 12, 2026
…L2 (plan r12, part 3)

#15, #17 and #14 are squash-merged (59545c1, d57fd9b, 0efd400). The plan and the
execution log say so, and main is now 0efd400 in the current-state text.

WSL2 works again. On 0efd400: Linux pytest 2,539 passed / 16 skipped / 31
deselected; `zypi --version` prints `zypi 0.5.0 (0efd400)` (a debug build
on ext4, not the CI release-dist artifact); the PTY scripts pass, except one
check of smoke.py, which is out of date since #12 (22/23). Section 10.15 gets a
part 3 with these results and the leftovers; the "not verified" lines that said
"WSL does not start" are brought up to date.

Only documents change.
zy1233 added a commit that referenced this pull request Oct 12, 2026
…(plan r12) (#16)

## Summary

This PR records the V0.5 release in the plan: what the release is, what must be true before the tag, and what is known to be wrong. It is revision r12 of the plan for the removal of the Rust agent runtime. Only documents change.

The milestone is on GitHub: [v0.5.0](https://github.com/zy1233/pi-python/milestone/1). Nothing is attached to it, because the conditions are written in one place (the plan).

The three PRs that do the work of the conditions are merged before this one: #15 (`59545c1`), #17 (`d57fd9b`) and #14 (`0efd400`), in that order, each as one squash commit. This branch is rebased onto `0efd400`.

- `docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md`: a new section "发布里程碑 V0.5" (what the release is, six exit conditions, known issues, what is not in it). The status, the next steps and the "not verified" list start from `main` at `0efd400`. Decision 16 is new, and #17 did it.
- `docs/PLAN/archive/PLAN-RUST-AGENT-RUNTIME-REMOVAL-EXECUTION-LOG.md`: section 10.15, with the reasons, the figures, the follow-up work, your three answers (part "续 2"), and the merges and the WSL2 checks (part "续 3").
- `docs/baselines/tui.md`: the numbers of the new release measurement.

## The six exit conditions

| # | Condition | State |
|---|---|---|
| 1 | CI is green on the commit that gets the tag | Green: `CI` on `0efd400`, `TUI CI` on `d57fd9b` (`0efd400` differs from it only in `release.yml`). Look again on the commit that gets the tag. |
| 2 | The Linux release binary is not larger than v0.4.0 | **Done.** 420,767,096 B (v0.4.0: 470,461,776 B, 10.6 % smaller). Run [38221952524](https://github.com/zy1233/pi-python/actions/runs/38221952524). |
| 3 | A dry run of the release build on Linux and macOS arm64 | **Done.** Run [38223353755](https://github.com/zy1233/pi-python/actions/runs/38223353755) built both and published nothing (27 min). The manual trigger is in #14, merged. |
| 4 | The PTY scripts on the v0.4.0 binary and on the new binary | **Skipped by you.** V0.5 does not wait for it. Which known issues come from v0.4.0 stays a guess. |
| 5 | The release notes | **Done** in #15, merged. They list the macOS binary and say that CI built it and nobody has started it. #17 added one entry and removed one known issue. |
| 6 | The tag `v0.5.0` | Yours. |

## After the merges, with WSL2 working again

You fixed WSL. These runs are on `0efd400` (details: section 10.15, part "续 3").

- Linux `pytest`: 2,539 passed / 16 skipped / 31 deselected.
- `zypi --version` prints `zypi 0.5.0 (0efd400)`, exit 0. That is a debug build on ext4. It is not the `release-dist` file that CI builds.
- `agentInfo.version` is `0.5.0` in a venv installed from the merged tree. An older editable install keeps the version it had when it was installed (the old `/tmp/wsl-venv`: 0.2.0).
- PTY scripts: `exit_matrix.py` 12/12, `print_exit.py` 4/4, `resume_matrix.py` 10 PASS / 3 GAP (the known gaps), `mode_probe.py` as in #12, `status_line_probe.py` 4/4, `net_audit.py --mock` 13/13 and with `--no-network` 13/13.
- **`smoke.py` is 22/23.** The failing check, "status line follows the switch", waits for the text `Second model` followed by a `·`. The screen shows the right label, `Second model`, the session file has the `model_change`, and the next turn answers. The check is out of date since #12. My inference, not tested on an old build: the `·` came from the `auto` flag, which #12 no longer shows in the normal mode. It is a script problem, not a TUI problem. It is not fixed here. The fix is one regular expression.

## Decisions for you

- The plan decisions 6, 8, 14 and 15 should be made before the tag. If they are not, they go in the release as known issues.
- The date of `[0.5.0]` in the changelog is 2026-10-12. Change it on the day of the tag. The known issues become public release text.

## Not verified

- Nobody ran the `release-dist` binary that CI builds; only a debug build of `main` ran. Nobody ran the macOS binary. The changelog, the README and the TUI guide say so.
- The two changed `if` lines of `release.yml` have run only on their false side. A tag push runs the true side.
- This round did not run the Landlock layer (kernel 5.10 has none), `smoke.py --sandbox`, or the whole Rust test manifest on WSL2. CI ran the manifest on `d57fd9b`: 8,665 passed / 0 failed / 22 ignored.
- The plan says that the version overrides of `pi-config` could stop working for a user config that needs a version above `0.5.0`. I found no default config that does, and I cannot see user configs.

## Verification

- Link check of the plan and of the execution log: plan 149 local and 81 external links, 47 reference definitions; log 43 local and 58 external links; 0 unused, 0 problems.
- `ruff check .` and `ruff format --check .`: clean (nothing in Python changes).
- The test counts, run ids and times come from the job logs (`gh run view`) and from the output of the runs on WSL2.
- The three merges used `--match-head-commit`. #15 and #17 merged with the tree that CI had tested (#17 was rebased onto `main` after #15, and `git diff` against its tested tip was empty). #14 merged onto a newer `main`, so `CI` ran again on the result, `0efd400`, and passed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant