On 7/7/2015 2:24 PM, Louis Dionne wrote:
Louis Dionne
writes: Glen Fernandes
writes: [...]
I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful.
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.
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.
What you are generally talking about is having some interface that may change in the future, or even in the very near future. While this is generally discouraged in good software I for one have never felt it necessary that some public interface detail never ever change, as long as the documentation explicitly tells the user that the change has been made. But I think what you are specifically talking about, which is that you will be making changes based on the review but you would like to release Hana as part of Boost before you make those changes, is not a good idea as far as Boost is concerned. Surely end-users can wait for Hana to be officially part of a Boost release until you have made the changes necessary and the regression tests show that your changes are passing its tests. In the meantime, simply by having Hana being part of the modular Boost tree, you will almost certainly get users interested in C++14 metaprogramming trying it out.