Re: [Boost-users] [serialization] class versioning changes in boost 1.42

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2010-02-28 23:00:24

> 
> 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.