Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Tell macOS binary users when a newer release is available

Closed
  • Is something wrong?
#543 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@LJY2000-max is already working on this.

Since Oct 29, 2026.

  • #545 by @LJY2000-max — open

Assessment

This issue has not been assessed yet.

Description

Problem

A candidate who runs the prebuilt macOS binary from the latest release has no way to learn that a newer build exists. Every successful build of main replaces latest (docs/install.md), several times a day at the current pace, but the running binary never says so. The only way to find out is to open the releases page by hand and compare the commit ./codetrial --version prints with the one the release names, since the package version stays 0.1.0 across builds. In practice that check is skipped, so candidates keep practicing on builds that already have fixes they are missing, and a bug report from such a build describes behavior main no longer has.

docs/desktop.md already lists automatic updates as something the desktop app does not do. This asks for something smaller than updating: telling the candidate that an update exists.

Proposed behavior

The lobby checks whether the latest release names a different commit than the running binary, at three moments:

  1. When the binary starts and the lobby first loads.
  2. When the candidate ends an interview and returns to the lobby.
  3. Every hour on the hour while the lobby stays open and no interview is running.

When a newer build exists, the lobby shows a dialog that names the running commit and the release's commit and links to the release page (or the macOS asset). No check runs and no dialog appears during an interview.

Scope

The CLI binary for macOS (codetrial-aarch64-apple-darwin.zip from latest) only, because macOS is the only platform I can test on. The check itself does not depend on the platform, so Linux, Windows and the desktop app's desktop-latest can follow once someone who can test them picks them up. Downloading or replacing the binary is out of scope: the candidate still replaces the executable by hand, keeping config/, as docs/install.md describes.

Acceptance criteria

  • A macOS release binary older than latest shows the dialog at each of the three moments above, with a working link.
  • A binary that matches latest shows nothing.
  • A failed check (no network, a GitHub error, the short window in which latest resolves to nothing while it is republished) shows nothing and does not affect the lobby or an interview.
  • Nothing is checked or shown while an interview is running.

Implementation notes

The running commit is already known: build.rs embeds the first seven characters of GITHUB_SHA as CODETRIAL_BUILD_COMMIT, and the release job creates latest with --target "$GITHUB_SHA", so the two can be compared directly. Moments 1 and 2 are one code path: leaving an interview navigates to /, so the lobby loads afresh either way.

Two ways to make the check, compared:

  • The server asks GitHub (GET /repos/sysprog21/codetrial/releases/tags/latest) and caches the answer, and the lobby asks the server through a new endpoint. The page's connect-src stays as it is, and one GitHub request per hour serves every open tab, well inside the unauthenticated limit of 60 requests an hour.
  • The lobby asks GitHub directly. This needs https://api.github.com added to connect-src in src/web/policy.rs, and every open tab makes its own requests.

The first keeps the page's policy unchanged, so I would start there.

Questions

  • Should the check be on by default, or opt-in, given that it sends a request to GitHub that the binary does not make today?
  • A build from source has a commit too, but usually not one latest will ever name. Should the check run only in release builds, for example only when GITHUB_SHA was set at build time?
  • After the candidate dismisses the dialog, should it stay hidden until the next release, or appear again at the next check?

Related

#153 (merged) made a binary report the commit it was built from, which is what this compares. #14 (merged) introduced the single rolling latest release this reads. #494 (merged) publishes desktop-latest for the desktop app. I found no existing issue or PR about update notifications.

Dominant language
Rust
Stars
215
Forks
141
Avg merge
1d 12h
Merged PRs (30d)
232

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sysprog21/codetrial

All issues in sysprog21/codetrial

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.