- Sort branches by last update date rather than branch creation date.
- “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!