
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