Some thoughts on the software’s auto-update design pattern

There are so many ways to get the program to have the ability of auto-update. But as I’ve known, there is no way can absolutely make sure the program will update itself as expected. For example, you have defined some data type, in your program and store the data locally. And you have happily distributed your product to thousands users. Then months pass, you add some details to the basic data type. You migrate all the user data properly, and everything gone fine. Not a single complain heard from you users. Things turned complicate when the third time you update your data type. Now you have 3 types of data. Some of your users may be still the oldest version. Fortunately, you have left a tag in the data type to mark the version of the data type. So you take your time to check the version, and implement 2 method to migrate the data.

How about if this pattern continues for around 10 times? How many migration methods you should implement? Nine, of course. But if for some reason some of your users have reversed the version to an old one? From the basic principles of combination, we need 10×9 which means 90 methods to meet the requirement. That sounds crazy.

The main problem is because you can’t be sure whether all the users have always updated to the newest version. In other words, you need to find a solution to sync all the users program version and don’t hurt their data. On one can predict the future, we never know how the data finally like.

To be continued…