2 EAS Update Issues/Proposals

  1. Sort branches by last update date rather than branch creation date.
  2. “Branch Promotion Flow” causes unintended reversion

(1) Sort Branches by last update date rather than branch creation date
When I make updates to branches with EAS Updates, the branches are sorted in order of branch creation date. I think they should be sorted by last update date instead.

My team has versioned release branches that collect over time (for easy reversion), but we keep a persistent staging branch. The staging branch gets buried under old releases because the branches are sorted by their creation date instead of their last update. We are constantly pushing updates to the staging branch, but it stays at the bottom of the list because its old.

(2) “Branch Promotion Flow” causes unintended reversion
We’ve been using a flow that closely resembles the Branch Promotion Flow. Every build we submit to the app stores has a new runtime version as it usually contains a new native dependency. But, as with the Branch Promotion Flow, older builds and newer builds both utilize a single “Production” Channel. However, as soon as we push an update with the new runtime version, everyone running the older runtime essentially gets reverted back to the code that was originally released to the app store under that runtime. All subsequent updates are lost since the Production Channel now uses an incompatible runtime.

I propose that the recommended approach should be to have a new production channel for each runtime version. So when I release a new build to the app store under runtime 2.7.0 and a channel called 2.7.0, all users still on runtime 2.6.0 will stay on the most recent update to the 2.6.0 channel.

I haven’t yet converted to using this flow, so let me know if you see any flaws with it.

Hope this helps!

@jrconsole - nice find on (2)! Not sure how we missed this when designing the flow (it was the basis of our whole system design).

Your proposed fix is probably the best option, so I’m updating the docs accordingly: https://github.com/expo/expo/pull/22125

We’re also looking into some alternative ways to address this, which I detailed in that PR.

Unfortunately I found it because it was causing issues for us, but yeah! Thanks for addressing it.

I know #1 is less critical, but it is very annoying that regularly updated branches stay at the bottom of the list, so maybe give some thought to that one as well.


To give more context to the issue we were facing…

There were multiple times where I would push a build with a new runtime version to TestFlight so our QA people could test it. When the QA people would find an issue, rather than make a new build I deployed an update via EAS Update. The QA people were then able to see that update on TestFlight and reevaluate it before submitting to Apple for review.

However, upon deploying the EAS Update with the new runtime, ALL of our active users were being reverted back to the update embedded in their older runtime build, because the new runtime build was still being evaluated on TestFlight.

I started getting bug reports for things I had fixed weeks ago, and it took me quite awhile to figure out what was going on.