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.