How can we improve the Windows platform?

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.

413 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    DamianDamian shared a merged idea: Make it possible to revert to a previous version of an app.  ·   · 

    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.

    8 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Simon JacksonSimon Jackson commented  ·   ·  Flag as inappropriate

        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 AppsLateNight Apps commented  ·   ·  Flag as inappropriate

        Cliff,

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 DaveHermit Dave commented  ·   ·  Flag as inappropriate

        @Cliff,

        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.

        Hermit

      • Cliff SimpkinsAdminCliff Simpkins (Sr Product Manager, Windows Phone Developer) commented  ·   ·  Flag as inappropriate

        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?

      • Anonymous commented  ·   ·  Flag as inappropriate

        *Occassionally an update with a critical bug gets past developer & certification testing...

      Feedback and Knowledge Base