6.8: the reference page from Max — date the .mxo on each build - #26
Merged
Merged
Conversation
…e package for every platform)
The external's bundle identifier shipped as max-sdk-base's unexpanded Xcode template,
com.74objects.${PRODUCT_NAME:rfc1034identifier}: only Xcode expands it. The object's CMakeLists
now expands it from the project name with the same rule — com.74objects.tap.python-tilde — and
the macOS CI job checks it. assemble-package.py leaves docs/PRODUCTION-PLAN.md out of the package
(docs/ still ships, for the reference page Max reads).
The plan records the uv discussion as 4.7 and the decision to attach one all-platform package to
every tag, v0.x published as pre-releases automatically, as 4.8.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019rVV9SkjkWmiBXFMT4whkz
min rewrites docs/tap.python~.maxref.xml when Max loads an external newer than the page, but it dates the external by its .mxo folder, which a rebuild leaves alone: in the checkout the folder dated from its first build, older than the page, so the page was never rewritten. (A freshly unzipped release has a new folder, which is why Max rewrote the installed package's page.) The macOS build now touches the folder after each link, and run.py says when Max has rewritten the page, so it gets committed. The page Max writes matches the committed one but for the description, which predated 2.4's text; this commits Max's. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019rVV9SkjkWmiBXFMT4whkz
#25 landed on development/v2 as a8d2e98, the same tree as this branch's bb083ad. The one conflict is the object's CMakeLists, where both added to the same if (APPLE) block: kept both, the bundle identifier from #25 and 6.8's touch of the .mxo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EaBE7c7xYRveqLrVTQTpQ5
tap
pushed a commit
that referenced
this pull request
Oct 1, 2026
Brings in #26's resolution against development/v2 (#25 landed there as a8d2e98), so this branch merges cleanly once #26 has: the only difference from #26 is 6.9's own change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EaBE7c7xYRveqLrVTQTpQ5
tap
pushed a commit
that referenced
this pull request
Oct 1, 2026
#26 landed as a squash (87a19bd), so its plan text conflicts with this branch's copy of it next to 6.9's lines. Kept this branch's plan: the result is development/v2 plus exactly 6.9's change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EaBE7c7xYRveqLrVTQTpQ5
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.
Stacked on #25. Only the top commit, eb046e2, is new here, and it edits the same block of the object's CMakeLists. Merge #25 first.
Why Max never rewrote the page from the checkout
min's
doc_updaterewritesdocs/tap.python~.maxref.xmlwhen Max loads an external newer than the page. It dates the external by its.mxofolder, and a rebuild only changes files inside that folder.In the checkout, the folder's date was from its first build (2026-08-05). That's older than the page (2026-09-27), so the page never looked stale. A freshly unzipped release has a new folder, which is why Max did rewrite the installed package's page (the clue recorded in 6.5).
I confirmed this by touching the folder: on the next launch, Max rewrote the page.
Fix
touchon the.mxofolder after each link. Windows needs nothing:.mxe64is a single file, and its date already changes when it's rebuilt. The code signature stays valid.run.pynow prints a notice when Max has rewritten the page, so the new version gets committed rather than overlooked.Checked (in Max)
Also updated
🤖 Generated with Claude Code
https://claude.ai/code/session_019rVV9SkjkWmiBXFMT4whkz