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-22 12:57:58

David Raulo wrote:
> Hi,
>
> It seems that the serialization library shipped with boost 1.42
> changed the way class versions are handled.  The version_type which
> used to be an unsigned int is now an uint_least16_t, although I found
> no mention of that in the release notes.
>
> The problem is that we are using a date-based versioning scheme for
> our classes (for example a developer making a change in some class on
> 2010-02-22 would increment the class version to 20100222).  This
> scheme worked great for a couple of years, and helped us fix our
> backward compatibility bugs after the fact.
>
> Unfortunately, these big version numbers do not fit in 16-bit
> integers. As a consequence, the version string output in xml archives
> with the latest boost-serialization for this example would be 46206
> instead of 20100222, breaking our reloading code.
>
> May I ask why this change was made?  Would it be possible to revert it
> for the next boost release?  If not, anyone has suggestions how we
> could fix our code while maintaining backward compatibility ? (we
> have old archives in the wild generated with various releases of our
> code, which we need to be able to reload).

The change was made to make the system more robust and portable. Other 
changes were made to suppress warnings which indicated potential problems.

Your system presumes that an int is 32 bits.  This assumption would make 
otherwise portable archives not portable to C implemenations whose int is 16 
bits. The version # was always assumed to be exactly that.  I didn't 
anticipate that this might be overloaded with some other data - like a date. 
Had this occurred to me, I would have advised against doing this in them 
documentation.

I realise that this is of cold comfort to you.  Here are some ideas.

a) You could tweak your copy of the library to use a 32 bit integer.
b) in the longer run, you could decline to use the versioning built
into the system and substitute your own based on dates.  This would
entail tweaking all your serialization implemenations to save your
"date version" as part of the data.

If I thought about it, I suppose I could come up with some more ideas.

BTW, I had experimented with an 8 bit version #, since it was (and is)
inconcievable to me that one could modify a schema more than 255 times
and still find it useful.  But this created a problem with text archives
outputing an 8 bit integer as a single (non-printable) character.

Actually, now that you've brought this to my attention, I would be
possible and maybe better to implement version as a special type
rather than a STRONGTYPEDEF which would give me what
I really want - which is an 8 bit version for binary archives and
readable text for text archives.

Sorry I can't be of more help.  Moral of the story is "Overloading
data leads to unanticipated consequences"

Robert Ramey

>
> Thanks for any help,
>
> David.