Problem
0.14.0 taught cprof doctor to compare the CLI on PATH against the installed
plugin, which catches the two halves drifting apart from each other. It cannot
catch both halves being old together: a machine sitting on 0.9.0 with a 0.9.0
plugin is internally consistent and silent, while the docs describe features it
does not have.
Nothing in cprof knows what the latest published version is.
Proposed behavior
cprof doctor reports an available update, from a check that runs at most once
a day:
$ cprof doctor
work: ok
cprof 0.13.0 is installed; 0.14.0 is available
run `brew upgrade dcotelo/tap/cprof` and `cprof update`
active profile here: workAdvisory only. Unlike version skew, being a release behind is not a defect in
the install, so this must not fail doctor.
Alternatives considered
- Read the version from the marketplace clone Claude Code keeps on disk. Zero
network, but only as fresh as the last claude plugin marketplace update —
checked while writing this, the local clone read 0.13.0 nine hours after
0.14.0 was published, so it would have stayed silent exactly when it mattered.
- A
SessionStart warning instead of a doctor line. Proactive, but it puts a
line in every session until you update, which is the wrong trade for
information that is never urgent.
- Reporting in the statusline. Rejected outright: the statusline runs every few
seconds and must never carry a network check.
Additional context
Surface: CLI (scripts/lib/update.sh alongside the skew check, reported by
cp_cmd_doctor).
Needs network, which is why the shape matters: the published version is fetched
at most once every 24 hours and cached under ~/.cprof/, reusing the
CP_CURL_BIN seam and the same cache pattern usage data already uses. No
network, no cache, a malformed response or a timeout all mean silence — exactly
as a failed usage fetch does today — and an opt-out belongs alongside
CPROF_NO_USAGE.
Related: the tap's formula can lag a published release by up to a day, so this
check will sometimes name a version brew upgrade cannot install yet. The
message should survive that without looking broken.
Problem
0.14.0 taught
cprof doctorto compare the CLI onPATHagainst the installedplugin, which catches the two halves drifting apart from each other. It cannot
catch both halves being old together: a machine sitting on 0.9.0 with a 0.9.0
plugin is internally consistent and silent, while the docs describe features it
does not have.
Nothing in cprof knows what the latest published version is.
Proposed behavior
cprof doctorreports an available update, from a check that runs at most oncea day:
Advisory only. Unlike version skew, being a release behind is not a defect in
the install, so this must not fail
doctor.Alternatives considered
network, but only as fresh as the last
claude plugin marketplace update—checked while writing this, the local clone read 0.13.0 nine hours after
0.14.0 was published, so it would have stayed silent exactly when it mattered.
SessionStartwarning instead of adoctorline. Proactive, but it puts aline in every session until you update, which is the wrong trade for
information that is never urgent.
seconds and must never carry a network check.
Additional context
Surface: CLI (
scripts/lib/update.shalongside the skew check, reported bycp_cmd_doctor).Needs network, which is why the shape matters: the published version is fetched
at most once every 24 hours and cached under
~/.cprof/, reusing theCP_CURL_BINseam and the same cache pattern usage data already uses. Nonetwork, no cache, a malformed response or a timeout all mean silence — exactly
as a failed usage fetch does today — and an opt-out belongs alongside
CPROF_NO_USAGE.Related: the tap's formula can lag a published release by up to a day, so this
check will sometimes name a version
brew upgradecannot install yet. Themessage should survive that without looking broken.