Repository navigation
sdk-tag: a new SDK asks the store plugins to repin - #240
Merged
Merged
Conversation
After publishing a new sdk-v* release, sdk-tag.yml sends `fizzy-sdk-release` (with the version) to every fizzyedit plugin the store registry lists, read from fizzyedit/plugins by each entry's homepage, so a new plugin needs no edit here. Each plugin's sdk-repin.yml runs plugin-build-action's repin.yml, which builds it against the new SDK and opens a PR when the plugin needs a release. Nothing tags a plugin. `repository_dispatch` needs a token with Contents write on the plugin repos: PLUGIN_DISPATCH_TOKEN. Without it, or without a readable registry, the step warns and the release is otherwise unaffected. CONTRIBUTING.md's release train says what follows a release. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
foxnne
pushed a commit
that referenced
this pull request
Oct 8, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Euk6iCavQdW7MG5FN2vvFw
2 of 8 tasks
foxnne
added a commit
that referenced
this pull request
Oct 8, 2026
Part of #226 ## What changes Two pieces pixi's dropper magnifier (fizzyedit/pixi#3) needs to be a clear liquid orb over its zoom, with no frost and strong refraction: native Liquid Glass on macOS, the app's glass everywhere else. And the SDK release that ships them, so the orb can be tried against `main` as soon as this merges. **`core.native_glass.offered`** - The app publishes each frame whether the OS draws glass declared outside a view drag (`publishOffered`, from `Popout.beginFrame`'s `nativeGlass()`). - A plugin that sees it declares its glass with `native_glass.add`. Fizzy's overlay of Liquid Glass already stays up while any glass is declared. - Pixi declares a clear piece (`frost = 0`, the lens alone) over a zoom it draws in the window, so the OS's lens refracts the window beneath. - Off macOS 26, or with native glass off, `offered()` is false. **`LiquidField.drawPicture` / `pictureMargin` / `lens`, and `glass_look.forLens`** - The app's glass as a lens over a picture the plugin drew. The middle is the picture as it is, with no frost, colour or lift; the rim bends and lights it. - It reads no capture, so the middle stays pixel-exact. - On the web, where no look is published, it is the earlier glass. `pictureMargin` says how far past the shapes the picture should reach for that glass's rim, at the strongest shape lens. **Tried and dropped:** pixi tried the drop zones' frosted glass with its zoom laid over it. On a Mac it read as a thick grey border or a flat rim. **Merged with main** (#234–#236, #239, #240). ## SDK impact - [ ] None - [ ] Core-only or additive: reaches plugins at the next SDK release - [ ] Fingerprint moved: recorded in `sdk/src/version.zig`, `sdk_version` untouched, PR labelled `sdk` - [x] SDK release: bumps `sdk_version`, lists the `sdk` PRs since the last `sdk-v*` tag `sdk_version` goes 0.2.17 → 0.2.18 (ef95301). Since `sdk-v0.2.17` this release carries: - this PR's core additions; - #223, #224 and #227's core (the one-slider glass, `glass_look`, `core.native_glass`, `core.screens`'s menus and dialogs). The fingerprint has not moved, so installed plugins keep loading. Merging tags `sdk-v0.2.18` and, per #240, asks the store plugins to repin. ## Verified - `zig test core/gfx/glass_look.zig`: 13 pass. - `zig fmt --check` and `zig ast-check` on the changed files. - `tests/integration.zig` compiles `drawPicture` and checks `pictureMargin`. - CI: Linux, macOS, Windows, integration and the Windows cross-build on this head. - [x] macOS: pixi's orb tried locally against this branch by the maintainer, who approved it. - [ ] Windows: - [ ] Linux: - [ ] Web: ## Follow-ups - pixi#3 repinned to `sdk-v0.2.18` once it's tagged. - The orb pinching off pixi's sample button and merging with it (the plan's next step for this consumer). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Euk6iCavQdW7MG5FN2vvFw --------- Co-authored-by: Claude <noreply@anthropic.com>
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
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.
What changes
Publishing a new SDK release now asks each store plugin to repin itself. Until now, five plugin repos were repinned by hand after every SDK release.
After
sdk-tag.ymlpublishes a newsdk-v*release, a new step sendsfizzy-sdk-release(with the version) to everyfizzyeditplugin in the store registry. It finds them throughfizzyedit/plugins'registry/*.jsonhomepages, so a new plugin needs no edit here. Today that's atlas, drive, ghostty, pixi and zig.Each plugin's
sdk-repin.ymlthen runsplugin-build-action'srepin.yml, which builds the plugin against the new SDK and opens a PR only when the plugin needs a release: its fingerprint moved, or it no longer builds (as a draft). Nothing tags a plugin.CONTRIBUTING.md's release-train section now says what follows a release.The pieces:
repin.yml+repin_zon.py, to be taggedv6sdk-repin.ymlSetup (yours)
v6on its merge commit.fizzyedit, those five repos (or all), Contents: read and write.repository_dispatchneeds that. Store it as this repo'sPLUGIN_DISPATCH_TOKEN:gh secret set PLUGIN_DISPATCH_TOKEN --repo fizzyedit/fizzyWithout the token the step warns and the SDK release is otherwise unaffected, so the order doesn't matter for safety.
SDK impact
sdk_versionchange, so merging publishes nothing.Verified
ghstubbed for the dispatch calls only. The registry reads were real.sdk-tag.ymlparses. The step runs only when the tag step publishes (steps.tag.outputs.publish), so a push that leaves the version alone dispatches nothing.gh workflow run sdk-repin.yml --repo fizzyedit/atlas.🤖 Generated with Claude Code