Re: [boost] [serialization] New version number in 1.34

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-06-19 11:49:06

Robert Ramey ha escrito:

> Jared McIntyre wrote:
>
> > So, my problem is that we need to move to Boost 1.34, but I need a
> > serialization library that interoperates with 1.33 serialization. I
> > could hack my code to post-process the file, but it would be ugly.
>
> Hmmm - If you're going to generate new data files and distribute
> them to be processed with the old binaries - why can't you distribute
> the new binaries at the same time?

Because there can be a deployed SW base whose users you cannot
force to upgrade --think WWW, servers are under your control and can
be cheaply updated,  while the deployed browsers will span several
versions and be in some cases older than you'd like.

Wouldn't it be wise if Boost.Serialization provided backwards compatibility
except when doing internal improvements or using new features? Are there
really such breaking changes in the 1.33.1-->1.34 transition, apart from
the number bump?
The decision of automatically making Boost 1.n+1 savers backwards
incompatible with Boost 1.n loaders is IMHO a bit controversial and
can become a barrier to upgrading (like the case we're discussing right
now.) This problem is akin to the ABI issues presented by C++ compilers:
breaking it should only be done if strictly necessary.
If breaking changes are actually present in Boost 1.34, how hard would
it be to provide a 1.33.1 compatibility mode to cope with these situations
and so facilitate users' upgrade from 1.33.1 to 1.34?

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo