Evaluating Revopush 2.0 differential updates for adoption and the getting-started docs don't cover our topology — hoping you can clarify before we plan the migration.
Setup
One React Native codebase (0.84.1, New Architecture/bridgeless, Hermes) shipping four white-label apps — same JS bundle, different Android product flavors / iOS schemes, so four distinct store binaries with different package names / bundle IDs (and different icons/assets), all at the same version.
Today (Revopush 1.x-style, release-react from CLI 0.0.13): all four white-labels share one Revopush app per platform (e.g. "App (iOS)" / "App (Android)") with Staging/Production deployments. Since the JS bundle is identical across white-labels, one release-react per platform serves all of them. Works great.
Questions
- Base releases in this topology:
release-native uploads an IPA/APK as the diff base — but we have four different binaries per version per platform. Should we upload one of them? All four (does the server accept multiple base binaries per targetBinaryVersion)? Or is the intended model one Revopush app per white-label (meaning 8 apps, 4× release-react per release, and per-flavor deployment keys)?
- What do diffs cover in practice — only the JS bundle + CodePush-managed assets (in which case the flavor differences in the base binary may not matter), or the broader binary contents?
- Hermes: our bundles are HBC (
--useHermes, CLI-compiled). Any constraints on byte-diffing Hermes bytecode, or is it diffed like any other file?
- Minor: the docs say to install CLI
0.0.10 — is 0.0.13 (current latest) fully 2.0-capable, or is the pin meaningful?
If the answer to (1) is "per-white-label apps", a rough pointer on migrating existing deployments/keys would be appreciated — that changes our rollout plan significantly.
Context for the curious: this is the same app from #40/#41 — we've just finished automating our binary pipeline, so the release-native base-upload step would slot into CI either way.
Evaluating Revopush 2.0 differential updates for adoption and the getting-started docs don't cover our topology — hoping you can clarify before we plan the migration.
Setup
One React Native codebase (0.84.1, New Architecture/bridgeless, Hermes) shipping four white-label apps — same JS bundle, different Android product flavors / iOS schemes, so four distinct store binaries with different package names / bundle IDs (and different icons/assets), all at the same version.
Today (Revopush 1.x-style,
release-reactfrom CLI 0.0.13): all four white-labels share one Revopush app per platform (e.g."App (iOS)"/"App (Android)") with Staging/Production deployments. Since the JS bundle is identical across white-labels, onerelease-reactper platform serves all of them. Works great.Questions
release-nativeuploads an IPA/APK as the diff base — but we have four different binaries per version per platform. Should we upload one of them? All four (does the server accept multiple base binaries pertargetBinaryVersion)? Or is the intended model one Revopush app per white-label (meaning 8 apps, 4×release-reactper release, and per-flavor deployment keys)?--useHermes, CLI-compiled). Any constraints on byte-diffing Hermes bytecode, or is it diffed like any other file?0.0.10— is0.0.13(current latest) fully 2.0-capable, or is the pin meaningful?If the answer to (1) is "per-white-label apps", a rough pointer on migrating existing deployments/keys would be appreciated — that changes our rollout plan significantly.
Context for the curious: this is the same app from #40/#41 — we've just finished automating our binary pipeline, so the
release-nativebase-upload step would slot into CI either way.