Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]
Robert Ramey writes:
David Raulo wrote:
- this is not mentionned anywhere in the documentation or in the API. - you have at least one user who lost backward archive compatibility because of this.
See below a patch against svn. Can we please discuss its advantages and drawbacks? - what good does it do: obviously in my case, restore backward compatibility.
Why can't you just patch your own copy?
From a comedic standpoint I think that's a good answer.
- it gives more flexibility to the versioning scheme. Two usefull such schemes were described previously in the discussion, where classes still have increasing integer versions, but are not possible with 8 bits storage.
- what downsides does appying this patch have? Maybe occuring a slight overhead on 16-bits platforms? If true, can this be actually measured? - Would this patch cause any regression? Break any user code which was working fine before? Break user archive backward compatibilty?
Would this not break compatibility with binary_?archive ? Currently binary archive stores the version as a 16 bit integer. Maybe it wouldn't but it's another thing that would have to be considered. Even if it didn't, this would break the "guarentee" that any serialization which works for one archive class is guarenteed to work with any other one.
I've wondered if Robert deliberately misspells guarantee in order to emphasize that there is no guarantee. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net (651) 251-9384
Brian Wood wrote:
Robert Ramey writes:
David Raulo wrote: Why can't you just patch your own copy?
From a comedic standpoint I think that's a good answer.
well as far a we know there is only one person affected with this problem. Rolling back this line to 1.41 code would leave the problem for other users to trip on. So in this case I think that's a good option. At least until some better opportunity is found. Another option is just to stay with 1.41. The main changes from 1.41 to 1.42 are related to handling exported types through DLLS. If this user isn't doing this, then there's not much benefit to upgrading in any case.
I've wondered if Robert deliberately misspells guarantee in order to emphasize that there is no guarantee.
lol - It's not deliberate - which I suppose illustrates the point even better ! Robert Ramey
Robert Ramey wrote:
Brian Wood wrote:
Robert Ramey writes:
David Raulo wrote: Why can't you just patch your own copy?
From a comedic standpoint I think that's a good answer.
well as far a we know there is only one person affected with this problem. Rolling back this line to 1.41 code would leave the problem for other users to trip on. So in this case I think that's a good option. At least until some better opportunity is found.
Another option is just to stay with 1.41. The main changes from 1.41 to 1.42 are related to handling exported types through DLLS. If this user isn't doing this, then there's not much benefit to upgrading in any case.
I don't think upgrade of individual libraries generally work very well. Did you test 1.42 serialization with 1.41 version of everything else and know that it compiles? - Volodya
Vladimir Prus wrote:
Robert Ramey wrote: I don't think upgrade of individual libraries generally work very well. Did you test 1.42 serialization with 1.41 version of everything else and know that it compiles?
I always do this. On my test setup, I have my boost tree. It is the current release version of boost. EXCEPT, I have the serialization library directories (there are three of them) switched to the trunk. So when I run the serialization library tests, they are always run against the most recent release. I update my whole base tree from time to time. For example now I haven't it done it since 1.42 came out so Any changes I make now for 1.43 are being tested against 1.42. So in general, the serialization library can be expected to be compatible with the most recent previous version. Of course this isn't exact since I will update my tree eventually - as I have to do to detect any breaking changes in dependent libraries. But in general, it has worked pretty well. Robert Ramey
- Volodya
participants (3)
-
Brian Wood -
Robert Ramey -
Vladimir Prus