How would you set an upgrade cadence policy for a team's React Native apps, given a new minor about every two months?

## The constraints you cannot change A cadence policy starts from React Native's own rules: - a **new minor** has shipped roughly **every two months**; - **minors carry breaking changes**, because React Native is still on 0.x; - only the **latest three minor series** are maintained, so a release leaves support about six months after it ships; - deprecated APIs survive **one further minor** and may be removed in the one after. Any policy that ignores these produces the familiar outcome: an app three or more versions behind, unsupported, facing a multi-step upgrade under deadline. ## Options | Policy | Effort per upgrade | Risk per upgrade | Time out of support | |---|---|---|---| | Every minor, after its first patch | small, frequent | low | none | | Every other minor | medium | medium | none, if done before End of Cycle ends | | Only when forced (store deadline, blocking bug) | large, unplanned | high | often months | There is no single right answer, but the table shows why the third row is the one to argue against. ## A reasonable default 1. **Track every minor.** Plan the upgrade when a new minor ships, and start once its first patch is out, which gives early regressions time to be fixed. 2. **Never drop below End of Cycle.** If the team skips a minor, the next upgrade must happen before the app's series becomes unsupported. 3. **Give it an owner and a budget.** A rotating owner and a fixed allowance each cycle turn upgrades into routine maintenance rather than a negotiation with product priorities. 4. **Gate on libraries.** Keep an inventory of native dependencies; an upgrade proceeds when every library supports the target or has a documented workaround. 5. **Verify the same way every time.** Upgrade Helper diff, release notes, clean builds on both platforms, automated tests and an internal build before the store release. 6. **Respect freeze windows.** Schedule upgrades away from peak business periods, and have a supported version to fall back on. ## Arguments you will need to make - **"We have no time this cycle."** Skipping is borrowing: the next upgrade inherits this one's breaking changes plus its own, and the support window keeps closing. - **"Let's wait for a big release."** React Native has no big releases to wait for; each minor is a slice of breaking change, and some, such as 0.83 and 0.86, have none that affect users. - **"Upgrading is risky."** Small, frequent upgrades are less risky than rare, large ones, because each is easy to test and easy to roll back. ## What the policy buys - **Security and crash fixes** arrive through normal patch releases. - **Store and OS requirements**, such as a raised Android target SDK, are met in advance. - **Library updates** stay possible, because library authors test against current versions. - **Hiring and onboarding** are easier on current tooling, and the team's upgrade muscle stays trained. ## Where Expo changes the picture For apps built with Expo, the unit of upgrade is the **Expo SDK**, which pins a React Native version; SDK 57, for example, ships React Native 0.86. The same reasoning applies, but the SDK's own release rhythm and support set the cadence, and that policy belongs to the Expo SDK versioning discussion. ## Measuring whether the policy works A cadence policy is only real if someone can see it being followed. Useful signals: - **Versions behind latest** for each app, reviewed at every planning cycle; the target is zero or one. - **Days in End of Cycle**: how long an app runs on a series that is about to lose support. - **Upgrade duration**: how many working days each upgrade takes; a rising trend means the process or the dependency set needs attention. - **Blocking libraries**: the count of native dependencies that held up an upgrade, which feeds back into the dependency policy. When these numbers stay small, the team has turned React Native's fast release rhythm from a recurring emergency into routine maintenance.