Subject: Re: [boost] Boost.Hana
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-07-08 05:07:36
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Louis Dionne
> Sent: 07 July 2015 19:25
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.Hana
> 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
> it possible to put Hana in a release along with a note saying "still experimental" or something
> this? From the library's point of view, being able to reach more users is a huge help because of
> 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
> are applied.
IMO Anything in develop branch will be viewed by users as somewhat experimental, especially by
something cutting-edge like Hana - and you'll get the benefits (and reports of trouble!) from the
test machines. Bleeding-edge users will start to get feedback (perhaps bloody).
Once it goes into master branch, if there are any 'breaking changes' that will cause the users
grief, you need to use the 'what's new' release notes to raise a big red flag. You can also use
this to give advance warning of changes that you will make in future releases.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk