Boost logo

Boost :

Subject: Re: [boost] [1.44] Beta progress?
From: Eric Niebler (eric_at_[hidden])
Date: 2010-07-21 16:28:17


On 7/21/2010 5:00 PM, Robert Ramey wrote:
> Ryan Gallagher wrote:
>>
>> 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.

That sentence doesn't parse. I think you're missing a "to" in there. MPI
doesn't have "to" support previous versions, presumably because the
serialized forms are only traveling across a wire and are never
persisted to disk. Is that right? Matthias, is that assumption correct.

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

Not quite there yet. You didn't answer Ryan's questions directly. Let me
see if I can:

>> Based upon your messages, it's not clear to me what this "fix" does.

It makes binary archives distinguishable from their incompatible
pre-1.42 variants. It provides a standalone utility to help users fix
their broken binary archives from 1.42 and 1.43. It requires users that
inherit from a binary archive to manually fix their code. It (does/does
not?) help users identify these places in their code.

>> Does it make it so that serialization in 1.44 will be able to read
>> binary archives from 1.41

Yes(?)

>> or does it make it so that serialization in
>> 1.44 will be able to read binary archives from 1.42/43?

No.

>> Or somehow
>> both? Is there a trac issue?

No(?)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk