Re: [boost] Boost XML Serialization Stability across library versions

Subject: Re: [boost] Boost XML Serialization Stability across library versions
From: Adlai Shawareb (adlai_at_[hidden])
Date: 2017-01-26 11:51:58

Have you had a chance to review this? I did look at the Outlook QuoteFix link on your website, but the Download section of that site is broken.

Regards,
Adlai

> -----Original Message-----
> From: Adlai Shawareb
> Sent: Wednesday, January 25, 2017 2:07 PM
> To: 'boost_at_[hidden]' <boost_at_[hidden]>
> Subject: RE: [boost] Boost XML Serialization Stability across library versions
> 
> >>On 1/24/17 10:01 PM, Robert Ramey wrote:
> >>>On 1/24/17 6:29 PM, Adlai Shawareb wrote:
> >>> Thank you. We are really looking at Boost Serialization as a way to manage
> changes in the data stored in the memory chip. In future versions we may add a
> float or remove an int, and need to be backward compatible with those
> changes.
> >>>
> >>> Is there a feature in Boost that would support managing data in that way?
> >>>
> >>> The only alternative to serialization we've come up with is to use unions and
> structs to selectively include or exclude data as the versions change.
> >>>
> >>> Thanks,
> >>> Adlai
> >>
> >> I think you're confusing two different questions
> >>
> >> a) The library maintains backward compatibility to your previous data.
> >> So if your data changes, you can still retrieve data from older
> >> archives. This is referred to as "versioning".
> >>
> >> b) The same system is applied to maintaining backward compatibility
> >> to structs from the standard library, - vector, optional, etc....
> >>
> >> c) some structures from the standard library don't have a version
> >> number encoded in the data. versioning is maintained by a library
> >> version number encoded in the header record.
> >>
> >> d) This also maintains backward compatibility when you change your
> >> compiler to another version.
> >>
> >> e) This is all described in the documenation along with examples.
> >>
> >> f) This has worked well. In a couple of very rare instances it has
> >> occurred this this versioning between libraries has been messed up
> >> for one or another data type. I regret this. I would like to see an
> >> expanded test suite to address this and hence be able to guarantee
> >> that this problem would never occur. Unfortunately, no one has
> >> expressed the view that this is sufficiently necessary in order to
> >> justify the expenditure required.
> >>
> >> g) In your case, I would recommend creating some tests of your own
> >> that you could run on every new version of the library so that you
> >> would absolutly that backward compatibility has not been broken.
> >>
> >> I thought you were referring to abi compatibility - which I don't
> >> believe can be guaranteed. But now I see this is not your question.
> >>
> >> Robert Ramey
> >
> > Thanks Robert,
> >
> > Regarding your suggestion to use text serialization. Since, over time, we will
> be adding and deleting data from the data set that we serialize, would the
> following be the right approach to managing the changes in the data that is
> de/serialized. I'm > > thinking that we would set the BOOST_CLASS_VERSION
> before de/serializing.
> >
> > {
> >                ar & mInt;
> >               If(version >= 2)
> >                              ar & mFloat;
> >                If(version >= 3)
> >                               ar & mInt2;
> >                ar & mFloat2;
> > }
> >
> > Regards,
> > Adlai