¶Updates

eterm can tell you when a newer version exists, fetch it, check it, and put it where the running one is. Each of those is a separate step, and the last two happen only when you ask.

¶What it does on its own

Thirty seconds after launch, and once a day after that, eterm fetches one small file from elyracode.com/eterm/latest.json. It says what the newest version is and where its zip lives. Nothing about you or your machine goes with the request — not a version, not an identifier, not the time. If the version in the file is newer than the one running, a strip appears under the session:

eterm 0.8.12 is out; this is 0.8.11 · Install · What changed · Later

Later puts it away for this session. What changed opens the release notes in a browser. Nothing happens otherwise; a check that fails, because the machine is offline or the site is not answering, says so under Updates in settings and nowhere else.

cmd-, → Updates turns the daily check off, shows what the last check said, and has Check now for when you do not want to wait for tomorrow.

¶Install

Install fetches the zip and unpacks it under ~/Library/Caches/eterm/. Before anything is moved, the unpacked bundle has to pass the same check Gatekeeper makes, narrowed to one answer: signed with a Developer ID certificate issued to eterm's developer, over eterm's bundle identifier, and unchanged since it was signed. A bundle that is unsigned, signed by somebody else, or altered after signing is thrown away and the strip says which. When the feed carries a digest, the download is compared against it first; a download that broke on the way is caught before the signature is even looked at.

Only then is the old bundle moved aside and the new one moved in. Moved, not overwritten: macOS kills a process whose signed executable changes underneath it, and a rename leaves the running one untouched. The strip changes to:

eterm 0.8.12 is in place. It starts on the next launch, or now · Relaunch · Later

Relaunch writes down the window as it is, starts the new eterm, and quits this one. The session comes back the way saved sessions always do — the layout and directories, not the shells' contents. That is why relaunching is a separate press and never automatic: a terminal has work in it.

¶When it cannot

The strip says why, and offers Download, which opens elyracode.com/eterm for doing it by hand: drag the new eterm over the old one. The reasons that come up:

• This eterm was started from a build. It is running from target/ or a bundle.sh bundle rather than an installed application, and there is nothing to replace.
• Could not move the old eterm aside: permission denied. The account cannot write to the folder eterm is in. Installing into ~/Applications instead of /Applications avoids that for good.
• The download is signed, but not by eterm's developer. The zip at the address the feed gave is not an eterm release. Do not install it by hand either.

¶Turning it off

[updates]
check = false

or the toggle under Updates. Off means nothing is asked and nothing is offered; a new version is something you hear about elsewhere.