Summary#
osy upgrade fetches the newest release for your platform, verifies it against the checksums the release
publishes, and swaps it into the directory the running osy lives in. It works the same on macOS, Linux and
Windows, which the install script does not. osy whats-new prints a release's notes in the terminal, and the
toolchain prints one line a day when a newer version exists, ending with both commands.
Signature#
osy upgrade # to the newest release
osy upgrade 0.9.2 # to a particular version
osy upgrade --check # only say whether a newer one exists
osy whats-new # the newest release's notes
osy whats-new 0.9.2 # a particular version'sDescription#
Where it comes from. The download goes through the same door every install uses, so it is counted like any
download, and the archive is checked against the SHA256SUMS the release carries before a byte of it is
installed. A download that does not match is deleted and nothing changes. The version check and the notes come
from the public release page, so neither is a statistic and neither reaches us.
How it swaps. The files in the install directory are moved into a .old/ folder beside them and the new files
moved in — a rename, never a copy over a running program, which is what makes it safe to run from the very
binary being replaced. The next run of osy removes the .old/ folder. If anything fails during the swap the
old files are moved back.
Your local platforms are replaced, not upgraded. A compiled app and its embedded database belong to the
compiler that made them — the platform model and the browser runtime both move between versions — so after the
swap every local platform this installation started is stopped and removed, and the next osy launch or
osy check starts a fresh one and recompiles your app. Data you seeded into a local platform is gone with it:
these are development servers, never local production, and Reclaiming the disk your local platforms use removes the same
directories on idleness. Your source, of course, is untouched.
The editor extension is a thin client of the toolchain — the language server is osy lsp, hosted in the
binary you just upgraded, so the editor is on the new compiler the moment it restarts the server. The extension
itself is versioned with the toolchain; if an editor on your PATH has it at the previous version, the upgrade
offers to update it, or names osy vscode install when it cannot ask (Installing the editor extension).
What it refuses. An installation that a package manager owns — Homebrew's, winget's — because swapping files under a manager leaves it wrong about what is installed; the message names the manager's own upgrade command.
The daily line. When a newer release exists the toolchain prints, before a command's own output and at most
once a day, a line naming the version and the two commands. It is on whether or not usage statistics are;
"updateCheck": false in ~/.osy/config.json turns it off. See Usage statistics (what is sent, and the two ids that let us count you once) for what the check sends
(a request to the release page with the toolchain's user agent, and nothing else).
Examples#
$ osy check
a newer osy is available: 0.9.2 (you have 0.9.1) — osy upgrade
what's new: osy whats-new · https://github.com/osysharp/cli/releases/tag/v0.9.2
…
$ osy whats-new
osy 0.9.2 (newer than yours)
- …
$ osy upgrade
asking the release channel for the newest version…
downloading osy 0.9.2 for darwin-arm64…
checking it against the release's SHA256SUMS…
unpacking…
installing into /Users/you/.osy/bin…
✓ osy 0.9.2 installed (9 entries in /Users/you/.osy/bin).
what changed: osy whats-new
2 local platform(s) from 0.9.1 removed (1 stopped first) — the next osy launch or osy check starts a fresh one and recompiles.
code has the Osy# extension at 0.9.1; update it to 0.9.2 now? [Y/n]See also#
Installing the editor extension — the extension that ships with each release.
Usage statistics (what is sent, and the two ids that let us count you once) — what the toolchain sends, and what the version check does not.