Robert Ramey ha escrito:
Jared McIntyre wrote:
So, my problem is that we need to move to Boost 1.34, but I need a serialization library that interoperates with 1.33 serialization. I could hack my code to post-process the file, but it would be ugly.
Hmmm - If you're going to generate new data files and distribute them to be processed with the old binaries - why can't you distribute the new binaries at the same time?
Because there can be a deployed SW base whose users you cannot force to upgrade --think WWW, servers are under your control and can be cheaply updated, while the deployed browsers will span several versions and be in some cases older than you'd like. Wouldn't it be wise if Boost.Serialization provided backwards compatibility except when doing internal improvements or using new features? Are there really such breaking changes in the 1.33.1-->1.34 transition, apart from the number bump? The decision of automatically making Boost 1.n+1 savers backwards incompatible with Boost 1.n loaders is IMHO a bit controversial and can become a barrier to upgrading (like the case we're discussing right now.) This problem is akin to the ABI issues presented by C++ compilers: breaking it should only be done if strictly necessary. If breaking changes are actually present in Boost 1.34, how hard would it be to provide a 1.33.1 compatibility mode to cope with these situations and so facilitate users' upgrade from 1.33.1 to 1.34? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo