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

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-02-25 03:38:53

Robert Ramey wrote:

>> In that case, the issue David encountered is unambiguously a bug in
>> Boost.Serialization, and should be fixed in a future version of Boost.
> 
> The version # was envisioned as a small integer.  All the examples
> tests and demos used this.  The problem comes about because it was
> unanticipated that someone would like to include actual data (ie a
> date in this case) in a version #.  Note that this is the first time in
> 9 years that this has come up.  

Well, I assume that most folks who use Boost.Serialization don't post
here to report what version scheme they have used. So, I suggest you
don't make broad conclusions based on the number of reports.

> So I think it's a little much to
> characterize
> it as a bug in the library.  It would better be called an unanticipated
> usage of the version #.
> 
>> Out of curiosity, do you store the Boost version number, or something
>> equivalent, when creating an archive?
> 
> No.

If you have changed the number of bytes used to store the class version,
and you do *not* store boost version number in archive, then how can
1.42 read an archive created by 1.41 -- even assuming the classes being
serialized did not change themself.

>>If not, how do you make changes
>> to the archive format (e.g. the change David found in 1.42.0) without
>> breaking old archives?
> 
> This is described in the documentation.  The version # is maintained
> on a class basis and is completely independent of any other number
> such as program or boost version.  A little reflection should make it clear
> why it pretty much has to be this way.

Unless you promise and document that format used by boost.serialize will
never change, it seems like you also have to include the version number
for the archive format itself.	

>> How would an application ever be able to exchange data with older,
>> deployed, versions of itself, without this capability?
> 
> Again, a little reflection will make it clear that an older version of
> a program can't anticipate changes in a subsequent version.  I'm
> sorry - it's just logically not possible.  Think about it.

Assuming the use classes are not changed, why program built with 1.41
cannot read archive created by 1.42?

- Volodya