fmauger
commented
5 years ago - Point 1 is guaranteed by design at two levels:
- the Boost/Serialization itself which takes care of structural changes in the serialization mechanisms
- the eos::portable(i/o)archive extension and its evolution "boost::archive::portable(i/o)archive", candidate for official merging) which has been created for this use case. If it does not work, this is a bug in the libs and the faulty version of the lib should not be used.
- Point 2 is more tricky: there is no guarantee that it should work even if it could practically. What matters here is the "library version" (see basic_archive.cpp in Boost source code) which is always stored in the archive's header. This number is increased each time there is a significant change in Boost/Ser. It may occur (but this is now very rare) that some structural identifier (basically a version/reference identifier used while serializing objects, a counter for a collection class) changes of type (an enum, an integral, a struct...). The library must keep a track of this to be able to recognize an old signature. If the change between two version of the lib does not concern the serialized data, then it is likely that the deserialization will work. In the other case, there is no mechanism that would allow an old version of Boost to deserialize an archive created with a more recent version of the library. This is a causality constraint.
- Point 3 is guaranted as in 1.
I add a Point4: now if user code (i.e. classes) relies on class versionning, the library offers some tools to ensure backward compatibility in the user serialization template methods (read an old version of a class and restore it as a new version in memory). It works well but requires care of course from the developper.
drbenmorgan
As discussed in #29, SuperNEMO would like to move to a newer Boost version to resolve serialisation issues on macOS with Boost 1.63, which we've been using for a while now.
I couldn't find anything in the Bayeux or Boost.Serialization docs on what, if any, guarantees there are on forward/backward readability of Bayeux's output files with newer Bayeux/Boost versions. For example
I think it would be useful to have a clear description of what is, and isn't guaranteed here. With real data starting to flow, SuperNEMO need to plan for long-term storage and reprocessing. We can handle fixed software versions for reading, but just need to know to allow that to be accounted for.