Peter Dimov
Jarl Lindrud wrote:
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?
I mean independent component development by multiple uncoordinated teams. For example, if you use boost::X in the project, its serialization support can't follow your global versioning scheme. It works if you control all pieces.
You need a version number for each component. If your program creates archives with objects from components C1, C2, and C3, then each one of those components should maintain a version number of its own. When your program wants to create archives for consumption by older versions of the program, it would have to supply four version numbers (3 component versions plus your own application version). That seems fairly manageable to me, much more so than class level versioning.