On Thu, 11 Mar 2004 12:25:37 +0100, Pavel Vozenilek wrote I appreciate the sentiment of trying to save time, but unfortunately I believe the 'branch' approach creates the opposite result. As ugly as the code for the old compilers is, it is still easier to maintain than 2 branches.
...lots o stuff snipped... Why this may work: - all existing infrastructure (the tests) could be reused w/o change.
Not true. Tests in date-time adapt themselves based on the config so that some tests are excluded/automatically failed for some compilers without actually compiling the code. Other libraries may need similar changes to support your proposal.
...more details snipped... - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'.
I believe this is the best idea in your post. I would be fine if new libraries ignore regression tests for old compilers. I think we already have a way of marking this in the regression tests, but this might be a way of saving the folks that run the regression tests time. And this would have the effect of freezing boost at the current level for users of old compilers. Over time this might become a significant incentive to move forward.
Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless.
I don't think you can assume this. For example, there is still work on smart pointers which have been around forever. Jeff