Re: [boost] Boost.Hana

Subject: Re: [boost] Boost.Hana
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-07-07 16:19:14

On 7/7/2015 2:24 PM, Louis Dionne wrote:
> Louis Dionne <ldionne.2 <at> gmail.com> writes:
>
>>
>> Glen Fernandes <glen.fernandes <at> gmail.com> 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.