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

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2010-02-25 04:31:33

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

IIUC, in 1.41.0 and earlier, the version number was an int. In 1.42.0, it is 
now 16 bits, which is a breaking change on just about every platform. The 
responsibility of dealing with this archive format change surely lies with 
Boost.Serialization itself? Or do Boost.Serialization users need to know that 
archives they write are not necessarily readable by later versions?

I can't see much middle ground here - either you're backwards compatible, or 
you're not.

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

I'm talking about changes within Boost.Serialization itself, not changes to 
user-defined types. The 32-bit-to-16-bit change that triggered this discussion, 
is a good example. How will Boost.Serialization in the future, know whether to 
read a 16 or 32 bit version number, from an archive? If it always reads a 16 
bit version number, then you've broken compatibility with all pre-1.42.0 
archives. If it always reads a 32 bit version number, then you've broken 
compatibility with 1.42.0.

To deal with this, you really need to know which version of Boost was used to 
create the archive.

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

Do you realize that e.g. Microsoft Word 2007 can be instructed to save files in 
such a way that they can be loaded with Word 2003? What is logically impossible 
about that?

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

Fair enough, but then it should be stated clearly in the documentation: 
"Archives created by one version of Boost.Serialization are *not* guaranteed to 
be readable by subsequent versions of Boost.Serialization.".

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

How can you call it robust? It is evidently not providing compatibility in 
either the backwards, or the forwards, direction.

Regards,
Jarl.