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-26 18:53:09

> 
> The version # has always been 16 bits.  The binary archive has
> always stored 16 bits for the version #.  The code used an int -
> whose size varies between 16 to 64 bits depending on the platform.
> Text archives convert the int to a string and this conversion doesn't
> trap when the number passes 16 bits.
> 

I see.

> > To deal with this, you really need to know which version of Boost was
> > used to create the archive.
> 
> There is a mechanism for addressing these kinds of issues - it's the
> library version # as described in the documentation.  So far, that #
> is up to 4.

Thanks, that's what I was after.

> >
> > Do you realize that e.g. Microsoft Word 2007 can be instructed to
> > save files in such a way that they can be loaded with Word 2003? What
> > is logically impossible about that?
> 
> Can Microsoft 2003 word load files created with Microsoft word 2007?
> That is what we're talking about here.

Of course it can. Try it yourself (Word 2007 -> File -> Save As -> select the 
relevant file type). This capability is fundamentally important for many 
applications, and there's nothing magic or logically impossible about it.

Networked applications need this capability as well. E.g. a newly developed  
client needs to be able to communicate with any number of older, deployed, 
servers.

> 
> Hmmm - I might be willing to say
> a) that the intention is to make such a guarentee
> b) and every effort has been made to that end
> c) and that every attempt has been made to anticipate the
> usage of the library
> d) and that the library has been in usage for many years
> e) and that versioning is a widely used facility
> f) that has had very few problems from users
> g) and that continual efforts are being made to make that
> guarentee stronger
> h) but that it's possible that there is something I haven't
> anticipated which will create a problem.
> 

I'm confused. You indicate here that backwards compatibility is an *intention*, 
and yet the Boost.Serialization documentation indicates that backwards 
compatibility is a *guarantee* (Contents -> To Do -> Back Versioning -> "... 
Currently, the library permits one make programs that are guarenteed the 
ability to load archives with classes of a previous version...").

For end users of Boost.Serialization there is a big difference between a 
guarantee and an intention.

* If backwards compatibility is a guarantee, then the breakage David came 
across is a regression, and would need to be fixed in a future version of Boost.

* If backwards compatibility is a (best-effort) intention, then you can indeed 
take a pass on this breakage, and leave David to deal with it himself. But of 
course then the documentation should state clearly that backwards compatibility 
is an intention, not a guarantee.

So which one is it?

Regards,
Jarl.