[Serialization] Compatibility of text archives in 1.36 and 1.34

Hi, I recently upgraded from boost 1.34 to boost 1.36. A version of my application built with 1.36 can read the text archives produced by 1.34, but a version of my application built with 1.34 cannot read the text archives produced by 1.36. Is this the behaviour that I should expect? Glenn -- Glenn Ramsey http://www.componic.co.nz

Glenn Ramsey wrote:
Hi,
I recently upgraded from boost 1.34 to boost 1.36. A version of my application built with 1.36 can read the text archives produced by 1.34, but a version of my application built with 1.34 cannot read the text archives produced by 1.36.
Is this the behaviour that I should expect?
yes. We currently guarentee the ability to read archives made by previous versions of the library. We do not guarentee the ability to read archives made by future versions of the library. Robert Raey
Glenn

Robert Ramey wrote:
Glenn Ramsey wrote:
Hi,
I recently upgraded from boost 1.34 to boost 1.36. A version of my application built with 1.36 can read the text archives produced by 1.34, but a version of my application built with 1.34 cannot read the text archives produced by 1.36.
Is this the behaviour that I should expect?
yes. We currently guarentee the ability to read archives made by previous versions of the library. We do not guarentee the ability to read archives made by future versions of the library.
Thanks Robert, Is there a way to have this type of compatibility, ie to tell version 1.36 that it should write the 1.34 format? This is an issue if you use a technique like this: http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/examples.html#boost... If you want to upgrade the library version used by the server and still support old (deployed) clients then the clients will not be able to deserialize communication from the server. Glenn

This is touched upon in the "To Do - future projects" in the documentation. Robert Ramey Glenn Ramsey wrote:
Robert Ramey wrote:
Glenn Ramsey wrote:
Hi,
I recently upgraded from boost 1.34 to boost 1.36. A version of my application built with 1.36 can read the text archives produced by 1.34, but a version of my application built with 1.34 cannot read the text archives produced by 1.36.
Is this the behaviour that I should expect?
yes. We currently guarentee the ability to read archives made by previous versions of the library. We do not guarentee the ability to read archives made by future versions of the library.
Thanks Robert,
Is there a way to have this type of compatibility, ie to tell version 1.36 that it should write the 1.34 format?
This is an issue if you use a technique like this:
http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/examples.html#boost...
If you want to upgrade the library version used by the server and still support old (deployed) clients then the clients will not be able to deserialize communication from the server.
Glenn

I have to admit that I don't know much about boost serialize yet. I plan to evaluate it for a project we're working on. But if that description of the version design is accurate, it seems very limiting. It sounds like it's only safe to use boost serialize when you've got complete control of the executable versions accessing the persistent data. If forwards and backwards executable and persistent data compatibility is a requirement, then maybe Thrift (from the Facebook guys) would fit the bill? Thrift has a versioning design that allows new executables to create new persistent data that can still be understood by old executables. Essentially each element of a Thrift structure is individually versioned with a unique ID. It's an interesting take on the versioning issue. Thrift is a very different approach than boost serialize though. It's primarily a cross language protocol framework, that happens to also support persistent storage. It uses a C-like definition language to describe the persistent or on-the-wire protocol structures. It then generates the corresponding code for all sorts of languages. Note that there's no support for object inheritance with Thrift objects, which is a significant limitation. Best, -- Allen Cronce On Aug 31, 2008, at 9:33 PM, Robert Ramey wrote:
Glenn Ramsey wrote:
Hi,
I recently upgraded from boost 1.34 to boost 1.36. A version of my application built with 1.36 can read the text archives produced by 1.34, but a version of my application built with 1.34 cannot read the text archives produced by 1.36.
Is this the behaviour that I should expect?
yes. We currently guarentee the ability to read archives made by previous versions of the library. We do not guarentee the ability to read archives made by future versions of the library.
Robert Raey
Glenn
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

If used according to the instructions in the manual, Boost serialization will guarentee that new executables will be able to read archives created by any previous version. It cannot guarentee that old executables will be able to read an archive whose definition is changed in the future. Robert Ramey
participants (3)
-
Allen Cronce
-
Glenn Ramsey
-
Robert Ramey