Koshi 0.4.0 — Update and versions

koshi update

The command checks GitHub Releases. When a newer version exists, it downloads the archive for the current OS and architecture, extracts koshi, and replaces the running executable, whichever way koshi was installed.

If the current version is latest, it prints koshi 0.4.0 is already the latest version and exits successfully. Network, platform, archive, permission, and install failures return an update error.

On Linux and macOS, the new file replaces the old one in one rename. A program file in a root-owned directory, such as /usr/local/bin, is installed with sudo install -m 755. On Windows, the running koshi.exe is renamed to koshi.old and the new one takes its path; koshi.old is removed on a later launch.

The running sessions move too

After installing a newer release, koshi update restarts each running session that can into it, and after them the router, the background process that tracks sessions.

A session keeps its panes, the programs running in them, and their scrollback. An attached terminal rejoins the session on its own. Sessions started by koshi 0.3.0 or 0.4.0 restart this way; a session started by an older koshi keeps its build.

A session that refuses the restart is named on standard error and keeps the old build until you end it and start it again.

A session refuses the restart when:

a pane's program stopped reading its input;
a pane has no terminal to carry;
this machine cannot run the new binary;
the new binary does not read the resume file this build writes.

A session running a koshi with no restart at all, one that still reports the old version after the restart, and one that answers nothing within ten seconds are all reported the same way.

Which build is running where

koshi version                  # the koshi program you just ran
koshi server-version           # every running koshi server
koshi server-version --session <NAME_OR_ID>
koshi server-version --format json

koshi version prints the same line as koshi --version:

koshi version
koshi 0.4.0

The two answers differ while an update rolls out — the program your shell runs is a newer build than the process answering it until every swap lands:

koshi server-version
kind     session                                       version
router   -                                             0.4.0
session  session-3f2a1c94-8e7b-4d15-9a02-6c5138ef7b40  0.4.0
session  session-91c4de07-2b53-41a8-bf6e-70d9a2c81f35  0.2.0

Cell	Meaning
a build, like `0.4.0`	The server answered and named it
`unknown`	The server answered and is too old to name its build
`not running`	Nothing is listening there
`unreachable`	The server could not be asked; the reason prints on standard error

A server that could not be asked does not stop the rest of the answer: the other rows still print, and the command exits 4. Everything answering exits 0, including a machine running nothing at all.

--session reports that one session and leaves out the router. It takes the session id or its exact generated name, and a name must match exactly one running session.

Startup checks

Interactive launches can check on an interval and ask before installing:

koshi.kdl

version 1

update {
    auto-check #true
    check-interval-days 14
    allow-prerelease #false
}

Startup check failures never block or crash a normal launch. koshi stores only the last-check time in update.json in its state directory; it never rewrites koshi.kdl.

allow-prerelease #true chooses the highest semantic version from recent releases, including pre-releases. Otherwise koshi uses GitHub's latest stable release.

Update and versions

The running sessions move too

Which build is running where

Startup checks

On this page