Skip to content

docs(packaging): drop stale "DMG produced by the Swift build" claim#1458

Open
cfbraun wants to merge 1 commit into
jundot:mainfrom
cfbraun:pr/docs-packaging-dmg-claim
Open

docs(packaging): drop stale "DMG produced by the Swift build" claim#1458
cfbraun wants to merge 1 commit into
jundot:mainfrom
cfbraun:pr/docs-packaging-dmg-claim

Conversation

@cfbraun
Copy link
Copy Markdown
Contributor

@cfbraun cfbraun commented May 27, 2026

Summary

Closes #1456. (Supersedes #1457, which was auto-closed when I renamed the branch — content is identical.)

After #1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg:

  • apps/omlx-mac/Scripts/build.sh release produces oMLX.app directly — grep -rn "hdiutil\|create-dmg\|\.dmg" apps/omlx-mac/Scripts/ returns nothing
  • No .github/workflows/ entry produces one
  • The Swift updater consumes DMGs from GitHub Releases but doesn't make them

Meanwhile packaging/README.md still told developers to "Open the DMG produced by the Swift build" — that DMG doesn't exist.

What's in this PR

Just the README fix. The Installation section now reflects what actually happens:

  1. Drag build/Stage/oMLX.app to /Applications, or open it in-place
  2. (steps 2–3 unchanged)

Plus a note that the Releases DMGs come from an off-tree maintainer pipeline, so end users follow the Releases path and this section is explicitly scoped to developers building from source.

Why no hdiutil step in build.sh?

An earlier revision of #1457 added an opt-in --dmg flag. Pulled it: a developer who built oMLX.app locally already has the artifact they need — dragging the .app to /Applications is the standard macOS install pattern. A DMG is a distribution wrapper, useful when shipping to users (single signed download, polished volume window); none of that helps the local-build flow.

The one niche where local DMG creation has value is dry-running the auto-updater download path — better served by hand-rolling a DMG once for that specific test than by paying a maintenance tax (and 5–10 s extra build time) on every release build.

If maintainers want the official Releases DMG pipeline brought in-tree (CI workflow, code-signing, notarization), that's a separate, larger discussion.

Test plan

  • cat packaging/README.md — Installation section reads coherently and matches what build.sh release actually produces.

After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing
in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces
oMLX.app directly. The packaging README still told developers to
"Open the DMG produced by the Swift build", which doesn't exist.

For local builds the .app is sufficient: drag it to /Applications or
open it in-place. No wrapper needed. The Releases DMGs come from a
maintainer-side pipeline not present in this tree; that's a separate
distribution concern and explicitly called out.

Closes jundot#1456.
@cfbraun cfbraun force-pushed the pr/docs-packaging-dmg-claim branch from aec730f to 825826d Compare June 2, 2026 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docs claim Swift build produces a DMG, but no script in-tree does

1 participant