"Robert Ramey" <ramey@rrsd.com> writes:
You have two choices about how I'll handle backward compatibility:
1. Require that all user-written archive headers be updated with the next release of this library
2. Leave enough of the old mechanism in place so that existing code will still work as long as it follows the header ordering rule with respect to export.hpp
Either of the above would be just fine as far as I'm concerned. Go for whichever is easiest.
1 is easiest.
From the mail on the user's list I don't think that many users actually create archives or derivations of existing ones. And adding a macro to an archive description is very small burden which occurs once per archive class - almost never. A small price to pay to eliminate the header order questions that the come up all the time. It would be nice if we could automatically detect that such a macro is absent and trap right there
I could probably do that at archive construction time, but I'd rather not add that layer of complication.
- but off hand I don't see a way to do this. We'll just have to add something to the documentation. Not a big deal.
okay, maybe three choices:
3. Tell me that archive authors outside the library *already* have to invoke some macro that I don't know about, and I can add the effect of BOOST_SERIALIZATION_DECLARE_ARCHIVE to that macro's implementation.
I don't think there is currently any such requirement. I would expect that most if not all archives derived from basic_oarchive.hpp or whatever. Maybe that might be useful - but as I said I don't see anyway to make the upgrade truely idiot-proof.
Well option 2 is pretty good in that department.
Please let me know which of those angles I should pursue.
So as I see it its the following
a) replace export.hpp with a newer version. b) add a macro to each archive class declaration file c) re-work the test to cover the new header order d) update documentation to reflect the above. (I can do this)
Although I don't mind doing c), I would appreciate it if you'd rework the test yourself, before I start. This isn't out of laziness, but out of a desire to be sure I know I've met your requirements and expectations. If I rework the test, I could implement something that you'll find unacceptable. You could put the new test on a branch to avoid breaking the regressions. Thanks for your cooperation. -- Dave Abrahams Boost Consulting www.boost-consulting.com