Version Rollback - with a difference

Hi Sam/Wyatt

I've been following threads discussing Version Rollback and I can imagine how difficult it seems to be to allow users to roll back to any previous version... There's issues about large file sizes, backwards compatibility, and a whole lot of other crazy things I don't even want to think about.

However, I am very interested in this feature, and I do have some ideas on how it might be possible to implement.

My first idea is to allow developers to 'Push' old versions as updates. This might be really useful if say a developer pushes out an update which messes things up, and then he has to push another update to get things back to a previous state. I have used this myself a few times - but the way I do this right now is to Copy the files from the 'last known good version' to a new folder, and create a new 'Version' of my application in WYBuild, and then 'Release' another update.So, if I have version 1 and 2 of my app, and I release a new version 3 of the app which is 'Bad', then I release another version 4, which is identical to version 2.A very simple way of streamlining this in wyBuild is to allow one to Build Updates from not just 'All Previous Versions' to the selected version, but from 'All Versions' to the selected version. This way, I simply have to build an update from 'All Versions' to version 2, and that also rolls back my version 3 users to version 2 instead of just version 1 to version 2. I'm not sure how easy this would be to implement, but it seems doable to me.

Another idea I have for rollbacks is a little more difficult to implement/perhaps needs more 'looking into'.This would be to allow the user (not the developer) to roll back to just the last version after an update. For most of my apps. The way I look at it, if there's version 1, 2, 3 of an app, and the user just updates from version 3 to version 4, then wyUpdate.exe should download two files: app.v3.to.v4.wyu, and app.v4.to.v3.wyuThen, during the update, it can execute the v3 to v4 wyu file, and if the user chooses to rollback (not sure what the GUI for this would look like), then it can run the v4 to v3 wyu file...

Just throwing some ideas. I really look forward to being able to roll back apps some day but WyUpdate/WyBuild have already made work so much easier for me... thanks!

A very simple way of streamlining this in wyBuild is to allow one to Build Updates from not just 'All Previous Versions' to the selected version, but from 'All Versions' to the selected version. This way, I simply have to build an update from 'All Versions' to version 2, and that also rolls back my version 3 users to version 2 instead of just version 1 to version 2. I'm not sure how easy this would be to implement, but it seems doable to me.

It's very doable, but the problem is that it can be confusing (especially for new users).

Then, during the update, it can execute the v3 to v4 wyu file, and if the user chooses to rollback (not sure what the GUI for this would look like), then it can run the v4 to v3 wyu file...

wyUpdate already supports rolling back during updates. For instance, if the user cancels the update or an error occurs then wyUpdate rolls back to the previous version. We could always keep this rollback info around (past the end of a successful update) however there are a number huge problems with that:

  1. Space. Some apps are large (many, many gigabytes) and storing rollback info would quickly fill up a user's harddrive.

  2. Backwards / Forwards compatability. We can't make assumptions about data files that an app reads & writes. For instance, let's say AppX 1.0 operates on binary blob files of format BlobX. Then the customer upgrades to AppX 1.1. They open the BlobX file with the new version -- AppX 1.1 converts the file to the updated BlobX format.

    Then, a week later, the customer finds huge showstopper bugs and decides to rollback to AppX 1.0. Unfortunately for this customer CompanyX failed to make the new BlobX file format backwards compatible.

    In other words we can't just let a customer rollback to old versions (because a company may or may not have made their file formats backwards compatible). We have to make this an explicit choice for the Company, not the user.

We've been thinking about this a while. We're probably going to end up going with a variation of what you suggested. For instance, you can "mark" a version as rotten and if there are no "newer" versions then the next time you click "Build Updates" wyBuild will make updates that go to the latest non-rotten build.

In other words you can push old versions on your customers.

Does this make sense? Does this seem like something that would be useful?

The 'Marking Updates As Rotten' method would have the same problems about backwards compatibility as the method I suggested. In your example above, if the developer realizes that App1.1 is 'rotten' and pushes an 'update' that would roll back the users to App1.0, then there would still be issues with backwards compatibility.

Backward compatibility is a tricky issue. Perhaps you could add a field to the Update Information tab that allows the developer to indicate if this new update is backwards compatible. This way you won't have to assume that something is backwards compatible - the developer could indicate that it is if it is.

But personally, for me, yes the 'Mark update as rotten' option would be really useful - although I personally think for a new developer, it would be more confusing than simply choosing 'All Previous/Newer Backwards Compatible Versions' instead of 'All previous versions'...

Reply
Discard post