Re: [Boost-users] boost::serialization Qestion about versioning.

From: Pfligersdorffer, Christian (Christian.Pfligersdorffer_at_[hidden])
Date: 2007-10-26 03:03:52

boost-users-bounces_at_[hidden] wrote:

> As I can see from the documentation the library has only a forward
> compatibility. 
> 3. Independent versioning for each class definition.
> That is, when a class definition changed, older files can
> still be imported to the new version of the class.
> Is there any way to achieve a backward compatibility?

Hi Oleg, in August I bothered the group with pretty much the same
question. Here is the answer the author of the serialization library
gave - I think there might be a follow up with some more details but you
will have to look that up if you're interested in it.

Robert Ramey wrote:
> Pfligersdorffer, Christian wrote:
>> Hello Robert, hello all,
>> 
>> I know it is stated in the boost::serialization library documentation
>> that per definition always the latest version of a class goes to the
>> archive. I wonder if there is a way to change this behaviour and
>> choose the version number for my class at runtime. Obviously this
>> feature would be useful in a system of two dependent modules where
>> either the producer or the consumer could by updated to a newer
>> version without the other one being neccessarily updated too. Maybe
>> this has already been discussed but I could not find anything about
>> it on the web. However my strong suspicion is that there is no such
>> option within the library and I will have to provide a solution
>> within the affected classes.
> 
> I dismissed this issue when it was recently brought up for the first
> time. 
> I had never intended to provide an option for making "backward
> compatible" so I had presumed that it wasn't going to be possible. 
> 
> Well, some people kept bugging me and I did a little investigation
> and found that it would be quite possible with just a little bit of
> tweaking - and an amplified section in the documentation.  
> So I guess it will be done with 1.35.  FYI, the reason its doable is
> just a side effect of the fact that I leaned hard on "symetry" (I
> know I'm an atrocious speller) in order to conserve brain surface
> area.  I suppose there is a lesson in there somewhere.  
>