Clarify behavior of versions in context of EAS Update

Expo Application Services (EAS)
1

The documentation for EAS Update’s integration with Sentry was recently improved - see Current state of Sentry sourcemap uploading with EAS Update - #2 by kbrandwijk and Using Sentry - Expo Documentation .

In reading the updated docs, I think I’m either confused or there’s some opportunity for clarification/improvement.

Namely, the new docs say the release should be set to (pseudocode) [bundleId]@[version]+[buildId]. It’s not stated explicitly but I imagine this is intended to be consistent with the native binary that the update will apply against.

My problem understanding this is that OTA update compatibility is based on the runtimeVersion, not necessarily the version+buildId pair. It’s possible that you could have a number of app store binaries in the wild that have different version codes but share the same native code and thus runtimeVersion. Specifying the sourcemaps with this pattern would, I think, mean you could leave out a subset of devices’ reports. (Assuming of course that release channels are in play; let’s assume they are all the same in this example.)

So my questions are:

  1. Would it make more sense to specify a custom release string for Sentry that is equal to the runtimeVersion? (That is, set it in the plugin config and use this same value for builds and updates.) This also makes running the sourcemap upload command less difficult to create.
  2. Regarding versioning, there seem to be a few questions over the years (e.g., Expo OTA updates and versions and OTA updates versionCode not increase) pertaining to the correct way to handle versions and updates. In my case, I’m choosing to do something semver-esque and increment major versions when bumping the runtimeVersion, and incrementing my version every time I build or push a release. I’m storing the version in an environment file and importing that value into app.config.js for Expo and my runtime code, e.g. for indicating the app version in HTTP user-agent strings. I think it might help to make App version management - Expo Documentation clearer on the correctness of version strings after updates are applied.
2

Related: Using EAS update, there's no `revisionId` in releases · Issue #297 · expo/sentry-expo · GitHub

Seems like you can homebrew whatever you want here, however I’d be curious if there’s a case to be made for runtimeVersion being part of the defaults instead of version+build.

3

I think also the explanation of the default values for release and distribution might need updating, here? expo/using-sentry.mdx at 87effa9b515e27406fadcd2f8ce0285fdd423135 · expo/expo · GitHub

4

Like the docs mention, you can override the default behavior by simply passing in different values for release and dist to the Sentry.init call, if that fits your usecase better.

We opted for this default, because that’s what Sentry’s own scripts (that we use during build for uploading the initial sourcemaps) default to, and that behavior is very difficult to override. Using runtimeVersion only for the updates would therefore always create a new release on Sentry for the update, which might not be ideal.

2 Likes