v0.2.0

What's Changed

• Update socktainer to v1.2.1, apple/container to 1.2.0 by @cap10morgan in #8

Full Changelog: v0.1.7...v0.2.0

v0.1.7

What's Changed

• Map concurrent-create races to Docker's 409 Conflict, not 500 by @cap10morgan in #7

Full Changelog: v0.1.6...v0.1.7

v0.1.6

What's Changed

• Drop tmate from CI: bootstrap container-apiserver into the system launchd domain by @cap10morgan in #1
• Honor docker logs --tail by @cap10morgan in #2
• Time-box startup housekeeping so a wedged runtime can't block the daemon by @cap10morgan in #4
• Menu bar icon reflects Apple container services state by @cap10morgan in #5
• Report honest versions for dev builds and the patched socktainer by @cap10morgan in #6

New Contributors

• @cap10morgan made their first contribution in #1

Full Changelog: v0.1.5...v0.1.6

v0.1.5

Fixed

• docker buildx build now works end to end. Two bugs were blocking it: Apple Container only materializes a container's filesystem at start, not at create, so buildx seeding files into its BuildKit builder container before starting it (its docker-container driver's normal bootstrap sequence) failed outright — Whalebridge now bootstraps such a container on demand (booting its VM without yet launching its command) so the seed succeeds, and the /start that follows reuses that same bootstrap rather than erroring on a redundant one. Separately, HostConfig.Privileged was silently dropped entirely; it's now treated as granting all capabilities (the closest available equivalent), which BuildKit's build container needs to mount build contexts. Verified against two real Dockerfiles (apt-get + multi-stage COPY, and Leiningen/Maven) built and run successfully.
• The 0.1.4 "container's runtime state is missing or corrupted" message was wrong for a container that simply hasn't been started yet — that case (like buildx's, above) now either succeeds automatically or, if the automatic recovery itself fails, correctly says to run docker start rather than docker rm -f. A container that genuinely started and then lost its state (e.g. an OOM kill) still gets the crash/docker rm -f guidance.

Full Changelog: v0.1.4...v0.1.5

v0.1.4

Changed

• Containers that don't request a memory limit of their own now default to 75% of host RAM instead of Apple Container's fixed 1 GiB — a limit tight enough that ordinary workloads (e.g. a Node/vite build) can OOM well under it. Configurable in Settings (10-90%, applies the next time Whalebridge starts).
• Errors against a container whose runtime state is missing or corrupted (most often from an abnormal exit, like an OOM kill) now say so and suggest docker rm -f, instead of leaking a raw Cocoa/POSIX error like "stdio.log doesn't exist" or "Rootfs not found" — covers docker logs, docker cp/archive operations, and docker export.

Full Changelog: v0.1.3...v0.1.4

v0.1.3

Added

• "About Whalebridge" menu item: a dialog with the app icon, current version, GitHub and Check for Updates buttons, and acknowledgment links to socktainer and Apple's container runtime.

Fixed

• The apiserver-restart fix from 0.1.2 only engaged when Whalebridge itself observed a runtime upgrade within a single run. It now persists the last verified apple/container version across launches, so a runtime that was upgraded before Whalebridge last started (by our own installer flow in an earlier run, or manually) still gets its apiserver restarted instead of trusting a stale already-running process.

Full Changelog: v0.1.2...v0.1.3

v0.1.2

Fixed

• Apple's container installer updates files on disk but doesn't restart an already-running apiserver, which can keep serving the pre-upgrade version until something restarts it. socktainer's own compatibility check pings that live process and would fail with a version-mismatch error even after Whalebridge detected the upgrade was installed. Whalebridge now restarts Apple's container services after a runtime install instead of just starting them if they weren't already running.

Full Changelog: v0.1.1...v0.1.2

v0.1.1

Changed

• Updated the bundled socktainer daemon to v1.1.1. Upstream absorbed our pull-progress patch as a native feature, so it was dropped rather than reapplied; the platform-branding patch remains.
• Renamed "Daemon" to "Whalebridge" throughout the menu bar UI (status line, start/stop buttons, log menu item, failure messages).

Full Changelog: v0.1.0...v0.1.1

v0.1.0

Initial release.

Added

• Bundles and supervises a patched socktainer daemon, exposing the Docker Engine API over Apple's native container runtime.
• Menu bar UI: daemon and Apple container runtime status, a Containers section listing running containers with a "Stopped" submenu, Docker context management, and a daemon log shortcut.
• Sparkle auto-update with a "Check for Updates" menu item.
• Launch at login, on by default, configurable from a new Settings window.
• Animated menu bar icon while the daemon is starting.
• CI on every push and pull request: app unit tests, socktainer's own test suite run against our patches, and a live integration job driving the real Docker API.
• Tag-triggered release pipeline: build, sign, generate a Sparkle appcast, and publish a GitHub Release.

Full Changelog: https://github.com/cap10morgan/whalebridge/commits/v0.1.0