How DevCapsule checks component freshness

In v0.3.0, DevCapsule checks upstream vendor metadata for supported catalog components and falls back to a maintained compatibility feed when a vendor endpoint fails or changes format.

What an update check establishes

devcapsule project versions check keeps six facts distinct instead of rolling them into one badge:

A newer upstream version does not make your pinned version broken or unsafe, and "no update reported" does not certify that software is free of vulnerabilities—DevCapsule does not query an external CVE database. Read the text beside each status label: available is not a security endorsement, and unknown can appear when upstream support status is not published even though a newer version was found.

Where the signals come from

Each discovery adapter reads public vendor metadata rather than downloading installers:

PostgreSQL client comes from the base image, whose lock records only the major version. Because the lock cannot tell which Ubuntu package revision or security backport is inside the base, the check reports major-version support dates without inventing minor-version upgrade prompts.

Today, Codex supports end-to-end preview, preparation, and local selection through devcapsule project versions. The remaining adapters report upstream availability and notices; there is no "upgrade everything" command.

Running a check

From your checkout on the host:

devcapsule project versions show
devcapsule project versions check

versions show is completely offline and also works inside a capsule, where it separates the running container's software from the host's next-launch selection. versions check runs on the host and queries feeds for components in your selected lock. It saves observations without changing that selection. Interactive devcapsule project run refreshes the check after a day, or when the selected version set changes. Pass --no-update-check to skip the live check for one launch while keeping cached critical notices active. Non-interactive launches never poll upstream feeds.

To try a newer Codex version on one checkout, follow Try a component upgrade and recover. When an upstream channel carries a critical security or deprecation notice, interactive project run asks how you want to proceed rather than swapping tools behind your back.

Maintained status fallback when a vendor check fails

Vendor release endpoints change from time to time without warning. When an adapter hits an HTTP error, timeout, or unexpected payload shape, the launcher fetches DevCapsule's versioned fallback feed and links to the maintained component status page:

• Matching happens locally against the adapter ID, launcher version, and platform. DevCapsule sends no project metadata or installed component list.
• A matching maintainer diagnosis can point to a newer DevCapsule release that fixes the adapter, or link to an open issue and workaround.
• Updating the devcapsule launcher fixes the check; it never alters your project lock or upgrades components on its own.
• If no current diagnosis matches, status stays unknown with the timestamp of the last good check. Transient network errors never block an offline launch.

Current service limits before V1

A scheduled GitHub Action probes the adapters once a day and publishes fresh observations alongside maintainer-reviewed diagnoses on the component-status branch. Feed timestamps and diagnosis review windows expire independently—a republished feed does not extend an unreviewed diagnosis, and expired or malformed feed data never triggers an upgrade prompt.

Before V1, this status feed is best-effort rather than an externally monitored service: