Re: [boost] [test] Boost.test failures in develop

Subject: Re: [boost] [test] Boost.test failures in develop
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-06 05:11:16

Le 05/10/15 23:50, Adam Wulkiewicz a écrit :
> Gennadiy Rozental wrote:
>
> Only if by saying "c++11 capable" you have in mind that it has an
> _experimental_ support of nearly all of the features of c++11. You
> forget about a fact that the user must want to enable the support for
> them. There are users which cannot afford compiling the code using an
> unstable compiler.
>
> Which btw means that the runner's setup shouldn't be altered in a
> Jamfile. If a runner desires to test Boost passing specific compiler
> flags he should be able to do it. We should at least be honest and say
> that Test doesn't work if compiled against the default STD version
> supported by a compiler.

We will fix this.

> [snip]
>
> This is so untrue. I don't know how the majority of the industry works
> but at least in a part I know about the reality looks different than you
> think. Believe it or not but there are companies which are bound to
> c++03 simply because they're shipping some major version of a product on
> a particular OS comming with a specific compiler.

It also happened to me, but what works best in that case what is to 
stick to a specific version and backport the fixes, which is much easier 
(because selective) than sourcing a new version of boost with hundreds 
of changes. If they need a new version, they first test if it works for 
them and increment their version if everything is alright.

Companies that heavily depend on a setup do that: they have to control 
the build environment totally, which means also the specific versions of 
their dependencies. There is a little bit of a control in production 
environments, and the desire of upgrading is less important than the 
overall functional stability of the products.

> And in the same time
> they want the latest Boost features and bugfixes so they're compiling
> against develop branch of a library.

I strongly disagree on the fact that develop branch has some contract 
with end users. Develop branch has mainly a testing and packaging value 
wrt. other libraries of boost, so the merges to master are cleaner and 
the potential coupling of libraries is properly handled. If some end 
user wants the latest bug fixes from develop branch, it's his choice to 
have a code that potentially breaks his/her code.

I would say it is also the same for master. I believe there is a big 
release effort at every release of boost to get things done properly, 
and this effort is not performed in between. Also the bug fixes are 
hardly announced nor published, and until there is no announcement, 
there is no commitment from boost side. So it is up to the end users if 
they want to upgrade from master: they might source a code that might 
break a contract.

> [snip]
>
> To be perfectly clear. I have nothing against Test dropping the support
> for c++03. It's up to the library author or maintainer what he will do
> with the library. My point is that this is a breaking change, a
> regression, and that there should at least be some planning involved, an
> announcement on the list that the support will be dropped so everyone
> would be able to prepare accordingly. Preferably a solution for those
> who don't want to use the new version or at least a clear declaration
> that there is not and there will be no such solution followed by some
> period of time when the libraries could drop the Test dependency, at
> least in those libraries which have a maintainer. Since we already have
> a rather unpleasant announcement behind us it's a good time for planning
> and a clear declaration. "I won't fix Test and simply move to c++11"
> would be ok too. Anything that allows to do some planning.

Talking about planning, I would like to know

- what is the policy of boost wrt. deprecation warnings? My opinion is 
that deprecation warnings, either from the compilation perspective or 
usage (eg. from the command line) is the best way to push the changes on 
the end user side. But I do not know what boost says about that.
On boost.test side, we want to deprecate some headers, function and 
macros, as well as runtime arguments.

- apart from public announcement of deprecation, is there currently any 
other way or good practice for making changes to the public API?

- if there is a deprecation, what is the amount of time before the 
deprecated feature is dropped, in terms of releases or years? Is boost 
clear on that or is it on the hands of the library maintainers? I think 
it would be good to unify this.

Best,
Raffi