Rob Stewart
On Jan 20, 2014, at 2:48 PM, legalize+jeeves@mail.xmission.com (Richard) wrote:
Why can't we simply make things better immediately and then look at anything that is new?
It's fair to say that many are inclined in your favor. Gennadiy has said your docs don't document the new state of the library, so yours will be short lived if the new state is adopted fairly soon. OTOH, if the new APIs are rejected, releasing the new version will be delayed or never occur making your version long(er) lived. Given the idea of linking to your version as documentation of the deprecated APIs when (if) the new version is released, your docs will be useful for some time either way, and that bolsters your case. Still, the question remains whether you're willing to document the new APIs, too.
Somewhere along the way, I think the difference between the current and new APIs has been exaggerated. As for as I'm aware, the only change is to the assertion macros, which move to a more natural syntax: BOOST_CHECK_EQUAL(a, b) becomes BOOST_TEST(a == b) BOOST_CHECK_LT(a, b) becomes BOOST_TEST(a < b) ... etc. BOOST_REQUIRE_EQUAL(a, b) becomes BOOST_TEST_REQUIRE(a == b) ... etc. BOOST_WARN_EQUAL(a, b) becomes BOOST_TEST_WARN(a == b) Other than adding documentation for BOOST_TEST, BOOST_TEST_REQUIRE and BOOST_TEST_WARN, and trivial changes to tutorials to favour those macros, everything Richard has written would remain the same. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)