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-28 22:46:14

> 
> > Even if there have been no changes to my classes, there have been
> > changes to Boost.Serialization archive formats between 1.35.0 and
> > 1.42.0.
> 
> I am not aware of any such changes.  It's possible that there might
> be a few special internal types which could be a problem.  I think
> I've trapped that situation, but as I write this, I don't remember.
> 
> Are you saying that 1.42.0 can "tweak" the archives so that
> > they will be readable by 1.35.0 ? If not, how is the 1.35.0-based
> > server ever going to be able to receive messages from the
> > 1.42.0-based client?
> 
> No such tweaking should be necessary.  Archive format is
> unchanged between boost versions.  The only thing that
> changes are the changes in users classes.  The user has
> to make special provision for such changes.

There is definitely a breaking archive format change in 
basic_binary_iarchive.hpp:110 (1.42.0) - collection sizes serialized as 
std::size_t rather than unsigned int.

Subversion tells me this change was made 4 August 2009, so I presume it was 
released in Boost 1.41.0 . I can't see any mention in the release notes.

When you test against older versions of Boost.Serialization, do you check that 
archives can be loaded in both directions, i.e. old version can load new 
archives and new version can load old archives?

Even so, this particular format change would go unnoticed unless you test with 
something like 64 bit Visual C++.

Maybe there could be a section in the documentation listing, for each release, 
any archive format changes that are made. That would be valuable to users who 
are wondering whether they can safely upgrade.

> 
> >> I'll add language to the documentation so that it's clear one should
> >> not use a number larger than 255 as a class version number.  And
> >> I'll enhance the code to trap on violations of this rule in the
> >> future.
> 
> > What about the "guarantee" of backwards compatibility? Do you still
> > feel that is an accurate description?
> 
> I do.
> 
> With proper usage of the library, users can be confident that current
> programs can read archives created by the very earliest version of
> the library.  This particular case is the first time it has been reported
> that an archive made by previous version of the library fails to load.
> 

Maybe a checklist in the documentation, regarding "proper usage", so one knows 
whether or not to expect backwards compatibility?

Anyway, your call. Thanks for the discussion.

Regards,
Jarl.