4 ms·

> It's time to move back to open (web) standards and take control back into our own hands! Wait till you discover that the web is also half controlled by the c

by o1y32 3y ago

> It's time to move back to open (web) standards and take control back into our own hands! Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.

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 ago
  Sure, 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 ago
    Right, 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 ago
      Yeah, 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.
Timshel 3y ago
And that hosting it might incur more maintenance work than just billing it. I certainly prefer a website to a random app that just exist to better track you. But I read the article more as they half hassed the maintenance ...
- jarm0 3y ago
  Typical "legacy application situation where no team is assigned to" here. At least I've never seen in my 15+ year career a legacy application, which has a very good maintenance/testing model in place. It will just not work because maintenance/testing needs also resources and updates, but if priorities are in different places then it's not possible. Of course as stated already multiple times - things could have handled in better ways, but this doesn't mean that Google should not allow to stop release at least. Anyway, lessons learned.
natch 3y ago
Apple is definitely not your friend if you refuse to get on board with prioritizing user privacy and security, just to put a reason behind it.

by o1y32 3y ago

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 ago
Sure, 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 ago
  Right, 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 ago
    Yeah, 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.

Timshel 3y ago

And that hosting it might incur more maintenance work than just billing it. I certainly prefer a website to a random app that just exist to better track you. But I read the article more as they half hassed the maintenance ...

jarm0 3y ago
Typical "legacy application situation where no team is assigned to" here. At least I've never seen in my 15+ year career a legacy application, which has a very good maintenance/testing model in place. It will just not work because maintenance/testing needs also resources and updates, but if priorities are in different places then it's not possible. Of course as stated already multiple times - things could have handled in better ways, but this doesn't mean that Google should not allow to stop release at least. Anyway, lessons learned.

natch 3y ago

Apple is definitely not your friend if you refuse to get on board with prioritizing user privacy and security, just to put a reason behind it.