Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk