also looking at this
feat(maps): add key-free native Android maps and shared map controls
#363
28 files
+1857
-481
| @@ -18,7 +18,7 @@ Do not run the hook again after it has written the section. | ||
| 18 | 18 | The tag starts [Releaser](../.github/workflows/release.yml); pushing a tag is |
| 19 | 19 | the publication trigger, not proof that the release finished. |
| 20 | 20 | |
| 21 | Both release and CI setup pin Pantry CLI 0.11.64 as well as the Pantry action | |
| 21 | Both release and CI setup pin Pantry CLI 0.11.93 as well as the Pantry action | |
| 22 | 22 | revision; leaving the CLI at `latest` would add a GitHub API lookup before the |
| 23 | 23 | build can even start. |
| 24 | 24 | |
| @@ -38,7 +38,9 @@ publishes the GitHub release. Only then does a separate job publish the Zig | ||
| 38 | 38 | package to pantry and notify the registry to index the complete release. |
| 39 | 39 | Discord is notified only after the complete release is public, never from an |
| 40 | 40 | individual platform's staging job. |
| 41 | The npm job separately scans and publishes the public JavaScript packages. | |
| 41 | The npm preparation job builds and scans the exact public JavaScript archives. | |
| 42 | The npm publication job waits for the verified GitHub release to become public | |
| 43 | and publishes those scanned archives without rebuilding them. | |
| 42 | 44 | |
| 43 | 45 | Watch the entire Releaser run, not just the release page. Confirm its final |
| 44 | 46 | status is green, the page contains all four `craft-*.zip` archives plus the |
| @@ -54,8 +56,8 @@ publishing the incomplete draft. Do not interpret a successful tag push or a | ||
| 54 | 56 | partial set of staged archives as a completed release. |
| 55 | 57 | |
| 56 | 58 | The GitHub release is gated as a unit; the underlying package registries do not |
| 57 | offer a cross-registry transaction. The Zig package waits for the completed | |
| 58 | GitHub release, but npm publication is deliberately independent and may become | |
| 59 | visible earlier. The final workflow status remains the release signal. If the | |
| 60 | post-release Zig publication fails, the GitHub release still contains the full | |
| 61 | verified archive set; rerun that failed job rather than republishing the draft. | |
| 59 | offer a cross-registry transaction. Both Zig and npm publication wait for the completed GitHub release. Either | |
| 60 | registry publication can still fail after the native archives become public, so | |
| 61 | the final workflow status remains the release signal. If a post-release registry | |
| 62 | publication fails, the GitHub release still contains the full verified archive | |
| 63 | set; inspect and rerun the failed job rather than republishing the draft. | |