We store objects in XML. Sometimes we update the base objects, then we have to save more data in our files to represent the extra attributes of our objects.
How to organize/implement a system to ensure backwards compatibility with old versions of our files?
The complicated part comes when looking at several versions at once.
Version 1 -> Version 2 -> Version 3 -> Version 4
Should we write four file readers, one for each version of the file to read it into the current latest version of our object? Or, should we keep all the old versions of the classes around from versions 1-3 so that the old readers can read the data into those classes, and then have incremental updaters to update 1->2 and then 2->3 and then 3->4.
When I increment versions like this I typically keep the old reader, and just update it to write into the new model. This means I only have the current model for the rest of my code to deal with, but I can still read old files. I would not keep old classes around, no matter what other choices you may make – you want to localize the number of places in your code that have to understand old versions to as few as possible (preferably one). If you keep old classes around, then any code that deals with those classes (even as derived from a common base) runs the risk of having to “know” about old versions, and that creates an unmitigated maintenance disaster after a while.
This is NOT a panacea…all the obvious options have issues. Once you have more than a few old readers, it becomes really time consuming to update them all (and god forbid you refactor some code they require into a new namespace and then have to edit effectively the same code 100 times to replace names). However, I usually just use this as a gateway to getting rid of old versions entirely – if you resolve to only have a few old version readers floating around for backwards compatibility, you can start deleting the oldest ones every time you make a new one, making the maintenance considerably less of a headache.