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