Louis wrote:
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
If the test matrix can be updated from Travis, that works too. Ultimately all we need is: - Test cases results/failures per compiler all viewed from one location: the Boost regression test matrix display - Easy for anyone to add/run a new test case, or update/run an existing test (which you've already achieved).
Oh yes, I forgot to ask: Does being included in a Boost release require the library's API to be stable? Is it possible to put Hana in a release along with a note saying "still experimental" or something like this? From the library's point of view, being able to reach more users is a huge help because of bug reports and improvements that can follow. If this is not acceptable, I'll skip one or two official releases and wait until all or most of the non-backwards compatible changes triggered by the review are applied.
(Paul and Edward gave you good answers). Stable is a good word to describe it. It is up to you as the library author, but interface-breaking changes are not forbidden nor unheard of in Boost (as you've seen). You'll want to use your best judgement depending on what you think is best for Hana, and for users of Hana. [You might even change your mind about the former, depending on the latter: Despite labeling it as experimental, if enthusiastic Hana users start using it in production code, you might be tempted to handle major changes differently]. As for the boring next steps (getting into github.com/boostorg, updating the sub-module in /libs, and the Jamfile.v2 for tests) we can talk off the mailing list, whenever you're ready. (Or you might already know the process for all of that anyway). Best, Glen