"Jeff Garland" <jeff@crystalclearsoftware.com> 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.
Yes, it is easier to keep with current state now and 'cleanup' would take many months or couple of years effort. It may (or may not) be outweighted in future with better maintenability and lower entry barier for users.
- 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.
- 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 test may be left unchanged. Config would be used only by them. 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.
I use now BCB heavily and prefere new libraries working there, if possible. However in few years I'll surely be using conformant system and then clean code will be advantage. /Pavel