soon.
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
I'd take that as a yes. As long as you've asked on the development list with a clear subject line, then you've given the community sufficient opportunity to say otherwise.
well, to me getting no reply, means neither yes nor no, but more a `don't know' or `don't care' ... but the question is, how to disable the library for non-c++11 compilers? e.g. shall the tests fail or be disabled, shall the library print a warning?
If you're not happy with this, then maybe ask on the steering committee list? (Although, they might not be happy with me for saying that....)
well, i was not aware that there is a separate list for the steering committee, was under the impression that the discussions about the boost development takes place on the boost-dev list ...
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
hartmut?
* merging boost.lockfree now is too late, for the next release, as it is not in trunk because of the reasons mentioned above. well, it is not like it could introduce any regressions ....
Sure, I'm sympathetic as it sounds like you've been left in the lurch. I don't know how the other release managers would feel about it though so I can't promise anything.
please don't understand me wrong, i don't want to push the library for 1.51 (nor did i do that for 1.50 when i raised that question in the first place) ... it took two years between review request and review and the review took place during last year's summer of code ... i simply don't want to wait for another three years tim