Best practices for upgrading user data when updating versions of software

Question

In my code I check the current version of the software on launch and compare it to the version stored in the user's data file(s). If the version is newer, then I call different methods to update the old data to the newer data version, if necessary.

I usually have to make a new method to convert the data with each update that changes user data in some way, and cannot remove the old ones in case there was someone who missed an update. So the app must be able to go through each method call and update their data until they get their data current. With larger data sets, this could be a problem.

In addition, I recently had a brief discussion with another StackOverflow user this and he indicated he always appended a date stamp to the filename to manage data versions, although his reasoning as to why this was better than storing the version data in the file itself was unclear.

Since I've rarely seen management of user data versions in books I've read, I'm curious what are the best practices for naming user data files and procedures for updating older data to newer versions.

Edit: The 'date stamp' stemmed form a discussion here:

https://stackoverflow.com/questions/8104812/does-releasing-a-new-version-of-the-app-delete-files-of-the-older-one/8104906#8104906

Since the question is too open-ended, I should say I'm looking for the recommended procedures for upgrading user data between versions.

If possible, it would be nice to see iOS / objective-c practices, but it's not required.

Answer 1

Dates are helpful for when you need extra information about when something was happening. There is no harm to adding them to a file that already contains a version number.

However, you can not use a time stamp as the sole indicator of what version is running, therefore deciding what needs updating. Just because you released 2 updates in the last year does not mean that someone with an install date within that range is using one of those two versions. If the user gets a copy of the installer, they can hold on to it for future clean installs and expect the software to update itself instead of getting the newest version.

Answer 2

As you've noted there is no real advantage of a date over the version number. And you do need to keep old conversions in order to support people who skip updates (my wife is bad at that).

One thing you might think about is some kind of inventory of the number of people on each version so you would know when you could drop old updates. Apple should be able to provide you with those statistics (but I have no clue if they do). Or you could possibly add a ping function that would send you the version number and some unique id each time the app is run for the first time after an installation or upgrade.

Answer 3

The immediate benefit of a timestamps I can see is that you then have a sequence. I'd recommend the timestamp be inserted into a constants file, though, at build time. This makes the timestamp indicative of the build version (not the time of installation/upgrade).

Other than that, though, I'd say it's up to you. You can easily write a class to help out with version sequencing, depending on your version naming method (1.x, 1.2.x, etc.).

Answer 4

In terms of iOS / objective-c, one of the best practices is to use key-value data, along with NSCoder. This allows you to update older data in a fairly straight forward manner.

Another option is to simplify things down to an NSDictionary and save the data out in JSON format (or similar). This has the advantage of significantly simpler common use, re-ordering of data elements between versions is easier to handle (typically you don't have to do anything) but the drawbacks of placing limitations on the data types that can be used and having to check for missing values as a separate process.

If the format of the value for a key changes you can, in some cases, get automated conversion during load (ex: [dataValue intValue] -> [dataValue stringValue] if dataValue is changed from an integer to a string). If needed, you can check the type manually (isKindOfClass/isMemberOfClass) and covert as needed.

As to whether or not to use a date stamp in addition to a version in the data, that depends on what you are attempting to accomplish. If you are just wanting to track compatibility of data between releases of the application then a date stamp has no more meaning than a version # (and perhaps less since it's harder to relate back to the app).

Personally, I use the the NSDictionary/JSON method where I can, and only use the NSCoder setup when I have complex data. If you have large structures that you feel may need updating several times over the course of your application's life span the I'd suggest using the NSCoder setup since it provides the cleanest method of updating data on the fly with the least amount of overhead.

Lastly, for straight C I use a setup for structures that provides simple version checking and data verification. Each struct that I (may) need to be able to update is layer out something like:

version
element1
.
.
elementX
id_tag

Version # is readable in a hex editor (ex: 0x00010000 == 1.0) and the tag is a 4 byte ResType (ex: 'pDat', 'TXT2', etc). I put the id_tag at the end after running into instances of other programmers updating my structures and not updating the version #. Doing so would cause any code attempting to use new data to fail because it's check to validate the data based on the old version # would not find the id_tag in the correct spot. It's not full proof (changing a 4 byte int to a 4 byte float would go unnoticed for instance) but it's decent, cheap, and helpful when viewing a data file with a bunch of these structures in a hex editor.

Hope that helps.