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-28 23:37:43

Jarl Lindrud wrote:
> 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?

No - but it would be a good thing to test.  Setting up such testing would
entail a lot of work though.  And the testing the serialization library
already consumes more resources than testing any other library.  If
someone wanted to make tests for this purpose, I would consider
adding them to the test suite.

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

Hmmm - This change - changing unsigned int to std::size_t - doesn't
seem to be an error to me.  binary archives are be definition across
platforms.  That is a binary archive created on a 32 bit machine
cannot be read on a 64 bit machine.  Since std::size_t is the same
size as unsigned int on all platforms, I don't think this should ever
create an error.

But I will say that this particular case is really a case of getting lucky.
Now that I think about it, I should have made the type conditional
on library version - even though I don't think it makes a difference
in this case.

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

If I knew about them, I would fix them before release.

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

I expect backward compatibility to be preserved.  It is an explicit
goal of the library.   As far as I know, this is the first case where
such compatibility has been broken.

Robert Ramey