LOL - my motto is that no good deed shall go unpunished - here are some ideas: for each class there is a BOOST_CLASS_VERSION(myclass, version_number) If this macro isn't included - its' the same as saying BOOST_CLASS_VERSION(myclass, 0) This version # is passed each time we serialize, save or load a class - that is: template save(Archive &ar, const unsigned version){ ... } the "version" above contains the current value set by BOOST_CLASS_VERSION for this class. Current common practice is to include BOOST_CLASS_VERSION in each header So the natural thing would be to have: // archive_version_header // type version for product version 0 #if product_version == 0 #define my_class_version 0 ... #elif product_version == 1 #define m_class_version 2 ... #endif and in the header for my class to ... BOOST_CLASS_VERSION(myclass, my_class_version) Finally, serialization function for my_class would template save(Archive &ar, const unsigned version){ if(version > 1) // only do this if creating version 1 files. .... } So alll you have to do is include in ALL your headers #define product_version 0 // 1, ... or pass it in the command line. #include "archive_version.hpp" So now you've done the whole job without changing the library! almost ... The missing pieces are: a) this would require compilation of separate executable to create "old style" archives. Simple and efficient - but might not be convenient depending on the application. Addressing this would be quite a task b) this doesn't address the fact that some types don't have versioning for reasons of efficiency. They only can be changed when the global serialization library version is changed. Basically this applies to stl collections included in the library. So one would have to make a funcition - set_library_version(int) to complement get_library_version() and alter the code which depends upon the archive version to produce the "old style" on request. Doable - but not trivial. Anyway - food for thought Robert Ramey "François Ramond" wrote in message news:b7ed6cc70908201247x459f7770rdf203e81208ff9c5@mail.gmail.com... That's exactly the problem I'm facing... thanks! From documentation : "A cursory examination of the code revealed that this would not be very difficult. It would require some small changes in code and some additional tests." -> I'll have a look at possible changes in the library code. Any hint of where to look to begin ? François On Thu, Aug 20, 2009 at 8:26 PM, Robert Ramey wrote: This subject has been brought up before and it touched upon in the docmentation: libs/serialization/doc/todo.html#backversioning You might want to undertake this project. Robert Ramey wrote in message news:001636eef81eefa4150471914868@google.com... Hello, I work on an industrial application which uses XML Boost Serialization as a way to store and retrieve production scheduling solutions from XML files. I've been using Serialization for years and I really enjoy the ease of use and the flexibility it provides. Recently, I released a new version (say V2) of that application, in which some C++ classes have additional attributes of new classes with respect to the previous version (V1). The new software (V2) can still read files serialized by the earlier version V1 (ascending compatibility), but XML files serialized by V2 cannot be read by V1. I guess Boost Serialization wasn't designed for such "descending compatibility", nevertheless, during industrial production some unexpected bug on V2 might require to use V1 again (as it is stable), without loosing the scheduling solutions generated by V2. From an XML file generated by V2, I somehow managed to remove the parts XML associated to the new attributes (the additional information can be skipped), and re-number some class_id to make the file readable by V1, but this is quite time-consuming, and I can't automate this process since the numbering of class_id depends on the solution serialized. Any idea to make V2 serialized files readable by V1, either by modifying V2 or by an automated process to edit the files (I can't bring any modification to the source code of V1) would be really appreciated. Thanks for reading till here and, hopefully, for your help, François -------------------------------------------------------------------------- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ------------------------------------------------------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users