Thank you much @henryd. The notion of a version increment solves this issue nicely. Appreciate your engagement here with the user base, very much. How about this thought: are the Bubble updates pushed out as specific times of the day? I recognize it’s probably both impossible to A) know if an update could potentially or not potentially break existing app structures and hence concretely know whether or not it should be a dedicated version increment, and B) to actually make every single update a version option. Hence, because we’re dealing with this rock and a hard place, perhaps if the high-frequency updates were put on scheduled release cadence, we could still anticipate potentials. AKA I know updates are pushed around 11AM EST every day, so I know prod ops needs to check health and logs at 11:10 every day.
Working for a particular large, and technically-disparate, large bank comes to mind here, where they managed hundreds of possibly-high-impacting prod updates per week. In events where testing the impacts of each one was impossible, the hard-rule was there was a set time and frequency for prod pushes (which was once and only once per week), so that all affiliates/departments/tech teams knew when to be on call and to watch for sudden defects and failures. The flip side of this is, if a dev missed the cutoff for his particular change, he had to wait for the next prod push round. No exceptions.
That sort of model could work here. Food for thought.
Appreciate you much.
EDIT: P.S. SEV1’s were always an exception. And the real cadence looked like all updates: once per week, always followed by a minor push 36 hours later of all the fixes that the weekly push broke haha. Emergency SEV2 fixes only, no additional dev, for that mini-push.