Jarl Lindrud wrote:
Robert Ramey
writes: (1) Archives created with *older* versions of Boost are not guaranteed to be readable in *newer* versions of Boost (as the OP has discovered).
The intention is that archives created by older versions of the librar and previous versions of the application are guarenteed to be readable by later versions or both. If this does in fact occur, I would consider it a mistake.
In that case, the issue David encountered is unambiguously a bug in Boost.Serialization, and should be fixed in a future version of Boost.
The version # was envisioned as a small integer. All the examples tests and demos used this. The problem comes about because it was unanticipated that someone would like to include actual data (ie a date in this case) in a version #. Note that this is the first time in 9 years that this has come up. So I think it's a little much to characterize it as a bug in the library. It would better be called an unanticipated usage of the version #.
Out of curiosity, do you store the Boost version number, or something equivalent, when creating an archive?
No.
If not, how do you make changes to the archive format (e.g. the change David found in 1.42.0) without breaking old archives?
This is described in the documentation. The version # is maintained on a class basis and is completely independent of any other number such as program or boost version. A little reflection should make it clear why it pretty much has to be this way.
(2) Conversely, there is no mechanism by which archives created with a *newer* Boost version can be guaranteed to be readable by a specific *older* version of Boost.
This is true. I don't see anyway of making such a guarentee and I don't seen any utility in being able to do this.
How would an application ever be able to exchange data with older, deployed, versions of itself, without this capability?
Again, a little reflection will make it clear that an older version of a program can't anticipate changes in a subsequent version. I'm sorry - it's just logically not possible. Think about it.
Consequently:
(3) It is not generally possible to write a program capable of reading archives that have been written by multiple distinct versions of itself.
Since (1) is not true, this does not follow.
Your response to David seemed to be essentially "too bad, maybe you can find a way around it yourself", so I can't see that (1) is being taken very seriously.
If I had an easy answer, honestly I would share it. Really. I don't. Sorry.
Of course... The point is that with a robust versioning scheme in place, archive format changes can be implemented without breaking older software.
There is a robust (and efficient) versioning scheme has been in place since the beginning. It was never designed to be able to hold extra data. It's unfortunate that I didn't trap such an unintended usage. I try really hard - but I haven't been able to trap every case where something is used in a way that doesn't occur to me. Robert Ramey.