docir — design documents Graph

Documents / Issues / issue-f0b537bde01a

An installer that exits 0 without upgrading was reported as already current

Why a pinned uv-tool receipt made `docir self upgrade` claim the newest build, and what docir now says instead of guessing.

issue-f0b537bde01aissueresolved#agents#cli#release
View as Markdown◉ View in graph

Symptom

docir self upgrade printed package 0.28.0 (already the newest build) on an installation that was not the newest build. docir self status on that same install, minutes apart, reported latest: 0.29.0, update_available: true.

Cause

The install had been created with an exact pin, which uv tool records:

toml
requirements = [{ name = "docir", specifier = "==0.28.0" }]

uv tool upgrade docir resolves within that recorded requirement, so there was one candidate and nothing to do. It exited 0 — and it printed the cause and the remedy:

text
Nothing to upgrade

hint: `docir` is pinned to `0.28.0` (installed with an exact version pin);
      reinstall with `uv tool install docir@latest` to upgrade to a new version.

docir captured that text and discarded it: _upgrade_the_package_then_restart printed outcome.message only when the installer declined to run or failed. On exit 0 it re-executed into an environment it had not checked, and render_upgrade then reported "already the newest build" from upgraded_from == __version__ alone, without reference to what is published.

This is not specific to uv. A pip held back by a constraint file exits 0 and says nothing at all — measured — so the general condition is "the installer succeeded and the version did not move", of which a pin is one cause.

Resolution

upgrade_package() reads the version the environment holds after a successful run, through a new VersionProbe port, and UpgradeOutcome.version_moved carries the answer three-valued: None is could not tell and falls through to the behaviour every release before this one had.

When it is False, docir does not re-execute — there is nothing to hand off to — and reports three things: that the version did not move and which release is being missed, the installer's own output verbatim, and one instruction that holds whatever the cause (docir self status names the method; then self upgrade --no-package). The store half still runs, so the command is not a failure.

docir does not diagnose the cause and does not repair the installation. Rewriting a recorded requirement would reverse a declaration whose reason docir cannot see — a team pinning docir so every member's build matches the store format their committed .docir/ was written by is the case adr-ab4598c6f707 is about — and uv tool install docir@latest --force is the wrong repair for four of the five requirement shapes a receipt can hold (editable, git, plain, pinned).

To amend: Re-verify: