
It's not impossible, but it's pretty hard in general, and not easy to automate. If you're using class-level (or instance-level) versioning, your old archive has classes X1..Xn with versions v1..vn, and your new archive has classes X1..Xm with versions v1'..vm'. First you need to keep track of all these classes in your source code, and there well may be hundreds or thousands, not all of them present in any one document. Then you need to remember the version number for each that went into the old documents. Then, on save time, you need to pass the library the whole (v1..vn) list, so that it would be able to pass you vi when it calls your saver for Xi. Finally, you have to deal with new classes that were added after the old app shipped. Laborious.
Indeed - I wouldn't want to use class level versioning to implement forward compatibility.
If, on the other hand, you use a single archive-level version number, this creates a central point that every class change needs to touch, and distributed development becomes a nightmare.
I've actually implemented this, where I work. We have a large distributed application, where forward (and backward) compatibility are essential requirements. It's by no means automated, and there are some thorny issues when development proceeds on separate branches. Basically you only want to make schema changes on the trunk of your codebase. Assuming relatively few releases, you can collect a whole batch of changes into one version number change. I'm not sure what you mean by distributed development?
Better versioning schemes may be possible, but nothing comes to mind.
Protocol Buffers was Googles way of dealing with these issues. Regards, Jarl.