skip to content

Your event-ticketing React Native app is on 0.84, three minors behind 0.87; why step through each minor instead of jumping straight to the latest?

level: seniorimportance: should knowfreq 45%

answer

  1. deprecation warns one release ahead
  2. smaller diffs isolate the breakage
  3. libraries support version ranges
  4. 0.85 moved the Jest preset
  5. 0.87 removed InteractionManager

basics

~20 s

Stepping 0.84 to 0.85 to 0.86 to 0.87 keeps each diff small, lets you see each deprecation warning before the removal it announces, and ties any regression to one release; a single jump mixes three sets of breaking changes into one failing build.

solid answer

~40 s

Each React Native minor may break things, and the policy removes a deprecated API no sooner than two minors after deprecating it. Jumping from 0.84 to 0.87 means meeting 0.85's changes (the Jest preset moved to `@react-native/jest-preset`, `StyleSheet.absoluteFillObject` removed, older Node dropped) and 0.87's (Strict TypeScript API by default, `InteractionManager` removed, Node 22.13, compileSdk 37, AGP 9) all at once, with no way to tell which caused a failure. Stepping one minor at a time keeps each Upgrade Helper diff small, surfaces warnings while the old API still works, and lets every native library move to a version that supports each step. Each step gets its own branch, build on both platforms and test pass; 0.86, with no user-facing breaking changes, is a quick one.

code

javascript · 4 lines
javascript
// jest.config.js after the 0.85 step
module.exports = {
  preset: '@react-native/jest-preset',
};

go deeper

for a junior

Recall that each React Native minor can break things and that stepping one minor at a time is the recommended path.

for a middle

Explain the deprecation cycle and why a warning on one minor can be a removal two minors later, using real examples like InteractionManager.

for a senior

Plan the multi-step upgrade: library inventory, one branch and build per step, releasable intermediate states and a rollback point before peak season.

for a principal

Treat falling three minors behind as a process failure and argue for a cadence that makes this scenario impossible.

## The situation An event-ticketing app built on React Native **0.84** has not been upgraded for three releases. With **0.87** the latest stable version, 0.84 has just moved to **unsupported**: no more patches. The team wants to reach 0.87 before the next busy sales season. The question is whether to jump directly or to go **0.84 → 0.85 → 0.86 → 0.87**. ## What each step contains | Step | Notable changes to handle | |---|---| | 0.84 → 0.85 | Jest preset moved to `@react-native/jest-preset`; `StyleSheet.absoluteFillObject` removed (use `StyleSheet.absoluteFill`); end-of-life Node versions dropped | | 0.85 → 0.86 | no user-facing breaking changes; edge-to-edge fixes on newer Android | | 0.86 → 0.87 | Strict TypeScript API by default (deep imports become type errors); `InteractionManager` removed (use `requestIdleCallback`); Node 22.13 or newer; `compileSdk` 37; AGP 9 support with recommended opt-outs | Jumping directly means absorbing all of these together, plus every native library update the three releases require. ## Why stepping wins - **Deprecations arrive before removals.** React Native's policy keeps a deprecated API for the next minor and removes it no sooner than the one after. `InteractionManager`, for instance, was deprecated long before 0.87 removed it. Upgrading one minor at a time means you see a deprecation warning while the code still runs, and fix it deliberately. - **Small diffs are reviewable.** The Upgrade Helper's diff for one minor is short; for three it mixes template changes whose reasons are spread across three release posts. - **Failures are attributable.** If the ticket scanner's camera screen crashes after a single jump, the cause could be any of three releases or a dozen library updates. After a one-minor step, the search space is one release. - **Libraries move in lockstep.** Native libraries publish versions for ranges of React Native. Stepping lets you pick, at each stage, a library version known to support that React Native version, instead of hoping one version spans the whole gap. - **You can stop safely.** Every intermediate version is a releasable state. If the sales season arrives mid-upgrade, the app can ship on 0.85 or 0.86, both still supported. ## A workable plan 1. Inventory native libraries and note which versions support 0.85, 0.86 and 0.87. 2. For each step, read the release post's Breaking Changes and Deprecations, apply the Upgrade Helper diff by hand, update libraries, run `pod install`, clean-build iOS and Android, run unit and end-to-end tests. 3. Fix every new deprecation warning before taking the next step, because the next step or the one after it may remove that API. 4. Merge each step separately, or at least keep it as its own commit, so a later regression can be bisected. 5. Ship at least one internal build per step for the flows that matter most: search, seat selection, checkout, ticket display and the scanner. ## When a direct jump is defensible A jump is not forbidden. The Upgrade Helper can diff any two versions, and a small app with few native libraries and good tests may manage it. Even then, reading every intermediate release post is not optional, because the breaking changes of 0.85 still apply when you land on 0.87. For an app with payments, a scanner and several native SDKs, the step-by-step route costs a little more calendar time and much less debugging. ## Releasing along the way Each step should end in a build that could ship. For a ticketing app that means: - an internal build per step exercised by the people who know the checkout and scanner flows; - store builds prepared from the step that is current when a release is due, instead of holding releases until the whole upgrade finishes; - a tagged commit per step as the rollback point, so a late regression on 0.87 can fall back to a known-good 0.86 build rather than to the unsupported 0.84. ## The lesson for next time Being three minors behind is the result of a missing policy, not bad luck. With a minor about every two months, a team that upgrades once per release, or at least before its version leaves the three-series window, never faces a multi-step upgrade under deadline pressure.

  • During a React Native 0.84 to 0.87 upgrade, why fix deprecation warnings before the next step?
    React Native keeps a deprecated API for the following minor and may remove it in the one after. A warning seen on 0.85 can be a build or runtime error on 0.86 or 0.87. Fixing it while the old API still works is cheap; fixing it after removal happens in a broken build.
  • A native library you depend on has no release supporting React Native 0.87 yet; what do you do?
    Stop at the highest step it supports, which is still inside the support window, and track the library's progress. Meanwhile check whether a maintained alternative exists, or whether a small local patch or fork is justified. Do not force the upgrade past a library that has not declared support.
  • Is 0.85 to 0.86 worth a separate step in this React Native upgrade?
    Yes, but a cheap one. The 0.86 release post states it has no user-facing breaking changes, so the step is mostly the template diff, library bumps and a verification build. Keeping it separate still preserves bisectability if something regresses.

A deprecation is a road-closure sign posted one junction before the closed road. Drive the route junction by junction and you always read the sign while a detour is still easy; skip junctions and the first thing you meet is the barrier.

saying these in an interview costs you the question

  • Skipping minors is fine because deprecated APIs stay forever
  • Deprecation warnings can wait until the build actually fails
  • One big jump is faster because you only fix things once
  • The Upgrade Helper diff covers everything the release posts list