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

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-02-27 00:44:04

Jarl Lindrud wrote:

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

Please reread my sentence above.

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

This capability is and has always been part of the serialization library.
It it included in the documentation, demos and tests.  Please read the
documentation.

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

This is all true. The only restriction is that a class version number
has to fit into 8 bits.  This leaves room for 255 versions for
each class.  In this particular case, the version "number" was
loaded with a 6 digit date.  It was never the intention of the library
to support this as it is unnecessary and would make some
archives bigger.  In never crossed my mind that someone
would want to do such a thing.  That is the problem - and
only problem here.

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

well it's tested every day.  I could say that its a guarentee
as long as the facility is used as expected.  But

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

It's only a guarentee if one follows the rules.  In fact he did get
a compile error when he tried to use a binary_archive which in fact
checks the size of the version number passed.  The problem came
up only because I added similar checking to the code for text
base archives.

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

lol - I write 30,000 lines of code with the intention of making no
errors.  I cannot guarentee that I have made no errors.

Robert Ramey