4 ms·
Apple aside, doing this kind of thing silently sucks for users -- one of the benefits of native applications over the web is having control over when updates co
by teacup50 11y ago
Apple aside, doing this kind of thing silently sucks for users -- one of the benefits of native applications over the web is having control over when updates containing potential regressions are inserted into your workflow.
- awinder 11y agoCouldn't this also aide in correcting regressions at the same time?
- robmcm 11y agoYes it's a double edged sword, in most cases I would favor the ability to update and fix the application without having to force users to manually install an update.
- teacup50 11y agoYes, but as a developer, you're less likely to ship regressions in the first place if your deployment process involves more structure (beta testing, internal code freezes, release branches containing only bug fixes, etc) than 'git push'. Of course, that runs counter to the "continual deployment" idea popular in web circles, but that's the entire point.
- awinder 11y agoThis doesn't prescribe which branch you do the git push to though. I'm sure you could just as easily set up a branching scheme where you went through testing and internal releases, and launched new code off a stable branchline
- mokkun 11y agoTotally agree with this. As a dev it might sound like a cool thing, but as a user it sucks. Many, many times I found myself not updating an app because I won't agree with the changes (UI, new features, etc) or new permissions that were required.