docs(packaging): drop stale "DMG produced by the Swift build" claim#1458
Merged
Conversation
b7d36e5 to
6b36c6f
Compare
5f79695 to
0368c07
Compare
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.
0368c07 to
3d5ee77
Compare
Owner
|
Thanks for cleaning this up. The docs-only direction looks right to me: the repo no longer creates a DMG, and the updater only consumes release DMGs. One small path inconsistency remains: from the repo root, build.sh stages the app at |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 releaseproducesoMLX.appdirectly —grep -rn "hdiutil\|create-dmg\|\.dmg" apps/omlx-mac/Scripts/returns nothing.github/workflows/entry produces oneMeanwhile
packaging/README.mdstill 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:
build/Stage/oMLX.appto/Applications, oropenit in-placePlus 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
hdiutilstep inbuild.sh?An earlier revision of #1457 added an opt-in
--dmgflag. Pulled it: a developer who builtoMLX.applocally already has the artifact they need — dragging the.appto/Applicationsis 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 whatbuild.sh releaseactually produces.