6 ms·
Yeah, that's also true, but at least this kind of problems can be handled by a roll-back or whatnot. Situation we're currently are in does not allow to do anyth
by jarm0 3y ago
Yeah, that's also true, but at least this kind of problems can be handled by a roll-back or whatnot. Situation we're currently are in does not allow to do anything while we know that bad build is in production and phones are updating to it automatically. That's the worst situation to be in.
- giantg2 3y agoSure, you own the servers so you can rollback. You don't own a user's device. If you want to rollback after a full rollout, all you do is build your new/rollback release from your previously working commit and update your version number.
- l72 3y agoRight, but in this case, changing the target API is what broke the app. Since Google won't allow you to release an update with an old target API, you can't just revert the change and increase the build number.
- giantg2 3y agoYeah, I was talking about general rollback for Android. In this specific case, they chose to rush and they didn't test (boo-hoo). It's like me complaining that the tools shouldn't have let my bug go to PRD even though I didn't test (and apparently didn't know much about Android as evidenced by not having a physical Android device). Same thing if your site cert expires, or browsers start blocking specific functionality/code/tags. Seems like they just want to complain about the thing they aren't familiar with.