David Abrahams wrote:
"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.
Well option 2 is pretty good in that department.
I don't think its worth any extra effort to avoid breaking existent archives in this trivial to fix anyway. And I would hope the the newer export.hpp is simpler than the current one is which is way overly complex. I just had to keep making it more elaborate as each compiler was added in. Factoring out some of this complexity into your "? library" would be a significant benefit from where I stand.
c) re-work the test to cover the new header order
Although I don't mind doing c), I would appreciate it if you'd rework the test yourself, before I start.
Hmm - I was just thinking the the header order in test_export.cpp would be inverted. This would break test_export until the new export.hpp was in. Again not big deal as far as I'm concerned since I don't think tests are even being run on the HEAD right now. If it turns out that more needs to be done to make the test past, then that would be sort of a red flag indicating that users would have to change all thier programs (not just archive_class headers) which shouldn't be necessary if I understand your proposal correctly. Note that I'm also asuming that no new information is added to the archive itself - which would create quite a splash. For this reason, (aside from the fact that serialization has more or less exhausted its budget for testing resources). I think this is better than making a new test. It will verify the user code won't have to be changed. Robert Ramey