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.