Skip to content

docs(release): match the release flow to models.ts - #1428

Merged
msluszniak merged 2 commits into
mainfrom
@ms/release-flow-update
Sep 8, 2026
Merged

docs(release): match the release flow to models.ts#1428
msluszniak merged 2 commits into
mainfrom
@ms/release-flow-update

Conversation

@msluszniak

Copy link
Copy Markdown
Member

The v0.10 rewrite removed every path and constant the version-tag section named, so RELEASE.md now describes files that do not exist.

RELEASE.md said on main
src/constants/modelUrls.ts gone, model URLs are in src/models.ts
src/constants/versions.ts gone (only under legacy/)
LIB_VERSION derives the tag no such constant; tags are literals
VERSION_TAG = in-development it is the published tag (resolve/v0.9.0)
PREVIOUS_VERSION_TAG does not exist; in-dev tag is NEXT_VERSION_TAG

The constants were renamed and their meanings swapped, which is the dangerous part. Old step 2 says to make VERSION_TAG resolve 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:

  • adapter package paths corrected (packages/bare-resource-fetcher, packages/expo-resource-fetcher), plus a note that the publish workflow reads the version from packages/react-native-executorch/package.json
  • a new HuggingFace artifacts section. The flow depended on moving release tags but never described it: publishing a .pte to a model repo changes nothing for users until the tag moves, and model repos are tagged independently of npm
  • link to the model card standard in the spec repo

Two things found while checking, not fixed here

Both are code, not docs, so they are left for separate PRs:

  1. packages/react-native-executorch/package.json has version: 0.0.0 on main, and that is the field the publish workflow reads.
  2. .github/workflows/npm-publish.yml calls ./scripts/create-package.sh, which does not exist on main (it is still on release/0.9). A stable publish from main looks like it would fail.

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
@msluszniak msluszniak self-assigned this Sep 7, 2026
@msluszniak msluszniak added the documentation Improvements or additions to documentation label Sep 7, 2026
@msluszniak
msluszniak requested a review from barhanc September 7, 2026 20:37
- 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

barhanc commented Sep 7, 2026

Copy link
Copy Markdown
Member

One more thing here are the links to github we have in documentation like the ones at the bottom of each task

Source Code
View the implementation on GitHub:

[src/extensions/cv/tasks/keypointDetection.ts ↗](https://github.com/software-mansion/react-native->executorch/blob/main/packages/react-native-executorch/src/extensions/cv/tasks/keypointDetection.ts)

these should probably be swapped on release to point to release tag, not main.

Nvm, the build-versioned-docs.sh already does that automatically.

@msluszniak
msluszniak merged commit 18c34cd into main Sep 8, 2026
4 checks passed
@msluszniak
msluszniak deleted the @ms/release-flow-update branch September 8, 2026 04:37
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants