Re: [Boost-users] [serialization] class versioning changes in boost 1.42

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-02-25 02:06:15

Jarl Lindrud wrote:
> Robert Ramey <ramey <at> rrsd.com> 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.