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-24 11:50:09

Jarl Lindrud wrote:
> Hi Robert,
>
> It's not all that clear from the documentation what one can expect of
> the versioning scheme in Boost.Serialization. It would seem (and
> correct me if I'm mistaken):
>
> (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.

> (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.

> 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.

> (4) It is not generally possible to write a program capable of
> writing archives that will be readable by multiple distinct versions
> of itself.

Same as above.

> Regardless of whether one thinks these issues are serious or not, I
> think they should at least be prominently documented, as the
> potential for pain is quite high. Essentially, the current versioning
> scheme can make it prohibitively difficult to ever upgrade the
> version of Boost that a particular codebase is using.

The case we're referring to has come up due the presumption of
a 32 bit version number.  I made the version # with a certain expection
of how it would be used - and it got used in a different way.  And
I failed to include extra code to enforce that expectation. When I
added such code later, you got caught.

Was it a mistake on my part to not include such code until now?
Maybe.  Was it a mistake to not make this expectation explicit
in the documentation. Maybe. Was it a mistake to presume that
a version # would be able to hold upto 4 G versions?  Maybe.

Does this help? Maybe - but probably not.

I spent a little bit of time thinking about this and nothing immediate came 
to mind.
I'll look at it some more when I have some time.  You might
want to add a track item and let me know if you come up with
some other ideas.

I'm not unsympathetic, but honestly, I can't forsee everything - though
I try.

Robert Ramey