Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-21 17:00:45

Ryan Gallagher wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:
>>>> I made a mistake in release 1.42 and 1.43 which will mean that
>>>> archives created by these versions won't be readable by subsequent
>>>> versions
>>>> of the serialization library.
> [snip]
>> Until it was discovered that a few type changes had broken the
>> ability to read previous binary_?archives.
>>
>> OK no problem - just wait until 1.43 comes out.  EXCEPT
>> I had neglected to bump the library version # .  Doh!!!.
>>
>> THAT is the real problem.
>>
>> I've got a solution to fix the problem
>
> Hi Robert,
>
> Based upon your messages, it's not clear to me what this "fix" does.
> Does it make it so that serialization in 1.44 will be able to read
> binary archives from 1.41 or does it make it so that serialization in
> 1.44 will be able to read binary archives from 1.42/43?  Or somehow
> both?  Is there a trac issue?

I'll recapilate the history in a little more detail.

a) 1.41 - every thing fine
b) 1.42 - 17 November 2009? make some fixes to addressess warning messages.
This actually exposed some dependence on undefined behaviorj
so it was judged a good thing
c) These changes broke MPI but this was not noticed at the time.
Doug Gregor checked in some changes to the serialization
library to address the MPI issue.  But this broke compatibility
with previous binary_archives.
d) 1.43 released
I spent a fair amount of time reconciling all the above.
This does require a change in archives which derive
from binary_?archive.  I am sorry about that, but I
could find no other way to reconcile all the requirments.
as far as I could see, the changes should be small
and perhaps trivial since MPI doesn't have support
previous versions.  I don't know as I haven't looked
into it in detail and there are some macros whose
function I don't understand.
e) My method of handling breaking changes in
serialization formats is to include the archive version
implemenation number in the archive header so that
subsequent code can handle old archives.  This
was stymied by the fact that in step b) above,
I failed to increment this library version # -
(I was only fixing a few warnings - right?).  So
I've had to add a program which will fix
native binary archives writting by versions
1.42 and 1.43.  I realise this is a huge pain
but I don't see any other way.

Normally I would say don't hold a release
for any issue in a particular library.  I'm giving
myself a break here because the longer I wait
the larger the number of archives will be created
that require the fix.  It's like an oil spill - the
longer you let it go the bigger the problem.

I hope that clarifies things.

Robert Ramey