Allow Developers to 'roll back' to a previous update without re-certification
Occasionally an update to an app gets past developer & certification testing and is released into the wild. Even if the bug is an easy fix for the developer it will take the certification team the standard 4+ days to certify the new build and publish it.
Instead of this we should be allowed to roll back to a previously published version without going through certification. That way the users will be back on a stable release (or will not be prompted for an update if they were still on the previous release) and the developer will not feel rushed to get their fixed update into certification.
If we release an update and subsequently discover critical issues, it would be good to be able to "disable/hide" the update and have the previous version visible instead,
Thanks folks for the suggestion and the on-going commentary. We’re marking this as ‘under review’ to acknowledge that the team is aware of this request. This is a very complicated/hard item for implementation, and there is a general feel that the new accelerated certification process alleviates much of the need (as an update can be published, for most folks, in less than an hour – rather than in 4 days).
That being said, continue to weigh in on the comments section.
Simon Jackson commented
Even with the rapid deployments (which are great) we would still need the rollback feature.
Consider the scenario:
1: new release published
2: Users complain of a critical issue introduced which causes the app to crash
3: It may take several days to resolve the issue and resubmit an updated release
So in this case it would be more preferable to revert the fix and cause devices to re-install the previous version (and prevent users who have not yet updated from installing it)
This gives a better experience to the users and can continue working on their previously working version which we work tirelessly day and night with gallons of Coffee fixing it.
Then we can make use of the fast publishing to push the update when it's ready and tested.
Love the new speedy publishing path but we poor developers take slightly longer to fix things
(also ignoring the whole, it works on my machine debate :P)
LateNight Apps commented
1) yes definitely
2) I dont think it would be necessary to have this option. I always do testing on a beta version, but even then sometimes a bug slips through that only affects live data, and once it has gone live I do additional testing to make sure everything is fine. If I find a critical bug that has potential to corrupt the save data or something like that then I just want to prevent that from happening. At the present time if I find something like that then it is an excrutiating stressful wait until the fix gets certified in the store in order to replace the errant upgrade.
1 - I think being able to go back one release is enough. This should only be used in emergencies. That said I think we should make sure this scenario is possible. v1.0 is released and is healthy, v1.1 is released w/ critical bug so developer rolls back to v1.0. Developer updates to v1.2 but finds that this update has a second critical bug. Developer should be able to roll back to v1.0 again since v1.0 was the last build in the store, v1.1 should not be the 'back-up release' since it was replaced with v1.0.
2 - I think we would want users to go back to the last healthy version. But even if only stopping more 'bad' upgrades is possible I still think this feature would be helpful.
Hermit Dave commented
I'd say that just having an option to allowing rollback as a meaning of stopping users (existing from updating and new from downloading) the last version and marking the previous as the last version would be a good step.
A couple questions for those on this suggestion to add clarity.
1 - Is having the ability to only move back one release sufficient? This would mean that a developer could only ever move (n-1) releases back, and that that the Store would not keep any additional 'backups'/'undos'.
2 - And is there an expectation that users could also move downgrade once the developer rolls-back the version (and therefore the phone/Store app would need to support 'down level upgrades'), or that the roll-back would only stop additional users from picking up the 'bad' version of the app?
Mark Allan commented
*Occassionally an update with a critical bug gets past developer & certification testing...