docs(release): match the release flow to models.ts - #1428
Merged
Conversation
Every path and constant in the version-tag section was removed by the v0.10 rewrite. `src/constants/modelUrls.ts` and `src/constants/versions.ts` are gone, model URLs now live in `src/models.ts`, and there is no `LIB_VERSION` to derive a tag from. The constants were also renamed and their meanings swapped, which is the part most likely to cause damage: `VERSION_TAG` used to mean the in-development tag and now means the latest published one, with `NEXT_VERSION_TAG` taking the in-development role. Following the old step 2 and repointing `VERSION_TAG` would move all 288 already-shipped model URLs onto an unpublished tag. Called out in a caution block rather than only corrected. Also: - fix the adapter package paths (packages/bare-resource-fetcher and packages/expo-resource-fetcher, not react-native-executorch-*), and note that the publish workflow takes the version from the core package.json - document moving HuggingFace tags, which the flow depended on but never described: publishing a .pte to a model repo changes nothing for users until the release tag moves, and repos are tagged independently of npm - link the model card standard in the spec repo
- step 3 lists all four published packages. webrtc was missing while step 7
told you to publish it, and the note explains why the two fetcher adapters
still need bumping: the core package ships the pre-0.10 API as
react-native-executorch/legacy, and that path throws at runtime unless the
consumer supplies an adapter from one of them. Only the new API has a
built-in fetcher.
- a new step for the native artifacts release. download-libs.js resolves
v${nativeLibsVersion}-libs at install time, so a missing or draft release
breaks every consumer's postinstall, and nothing in the flow mentioned it.
- note that both publish workflows take a dry-run input, worth using first
since a publish cannot be taken back.
barhanc
approved these changes
Sep 7, 2026
Member
Nvm, the |
msluszniak
added a commit
that referenced
this pull request
Sep 8, 2026
…ion (#1429) Publishing from `main` is currently broken in two ways. Found while updating RELEASE.md (#1428). 1. `.github/workflows/npm-publish.yml` runs `./scripts/create-package.sh` from `packages/react-native-executorch`, but the rewrite scaffold (#1256) deleted that script. The workflow is byte-identical to the one on `release/0.9`, so it was never updated for the rewrite. 2. The core `package.json` still says `version: 0.0.0`, and that is the exact field the workflow reads to decide what it publishes. Set to `0.10.0`, matching the two adapter packages and `nativeLibsVersion`. ### Three deliberate changes from the release/0.9 copy | change | why | | --- | --- | | `yarn prepare` instead of `yarn bob build` | `files` ships both `lib/` and `legacy/`; prepare is `bob build && tsc -p legacy/tsconfig.json`. Bob alone leaves `legacy/` out of the tarball. | | version edited by pattern, not line 3 | `nativeLibsVersion` now sits directly below `version`, so a positional edit is one inserted line away from rewriting the wrong field. | | `build.log` written with the packed file list | The workflow greps it to assert no `node_modules` were packed, but nothing ever wrote the file, so grep failed on a missing file and the check passed vacuously. | The `build.log` content is the tarball listing rather than the pack output on purpose: `npm pack` runs the `prepare` lifecycle, and bob logs the path of the `tsc` binary it falls back to, which lives under `node_modules` and fails the grep on a package that is perfectly clean. That false positive showed up on the first test run. ### Verified by running the script - builds `react-native-executorch-0.10.0.tgz`, 1020 files - packed `package.json` says `0.10.0` - zero `node_modules` entries in the tarball, and the workflow's grep now returns 0 - `lib/` 496 files, `legacy/` 294 files Not covered: the workflow itself is unchanged here, so the first real publish is still the first end-to-end exercise of the CI path.
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.
The v0.10 rewrite removed every path and constant the version-tag section named, so RELEASE.md now describes files that do not exist.
mainsrc/constants/modelUrls.tssrc/models.tssrc/constants/versions.tslegacy/)LIB_VERSIONderives the tagVERSION_TAG= in-developmentresolve/v0.9.0)PREVIOUS_VERSION_TAGNEXT_VERSION_TAGThe constants were renamed and their meanings swapped, which is the dangerous part. Old step 2 says to make
VERSION_TAGresolve to the upcoming release; doing that today repoints all 288 already-shipped model URLs onto an unpublished tag. That gets a caution block, not just a correction.Also in this PR:
packages/bare-resource-fetcher,packages/expo-resource-fetcher), plus a note that the publish workflow reads the version frompackages/react-native-executorch/package.json.pteto a model repo changes nothing for users until the tag moves, and model repos are tagged independently of npmTwo things found while checking, not fixed here
Both are code, not docs, so they are left for separate PRs:
packages/react-native-executorch/package.jsonhasversion: 0.0.0onmain, and that is the field the publish workflow reads..github/workflows/npm-publish.ymlcalls./scripts/create-package.sh, which does not exist onmain(it is still onrelease/0.9). A stable publish frommainlooks like it would fail.