This all sounds great. Just to be clear, we're talking 0.9.3 this
On Mon, 13 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote:
> I'd like to polish a release this week if possible. Roy'd previously mentioned calling it 1.0, but I'd like to go with v0.9.3 because
> 1) I'm not aware of anything drastically different vs 0.9.2, but correct me if I'm wrong;
> 2) In any case I'd like to wire brush the code and remove all the APIs that have been deprecated for ages;
> 3) I'd like to remove the default comm_world business for 1.0.
> So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on.
week, then 1.0-rc1 ASAP after we go through and shred deprecated
stuff? My "warnings fixes" branch might be worth merging into the
> But what about C++11? I could see 1.0 as a 'maintenance stream'
> where we back port important bug fixes but otherwise leave it alone.
Gah. I can't believe *I'm* objecting (my current app development is
using C++1y features, which like C++11 features are awesome), but
AFAIK full C++11 support is *still* limited to g++ and clang++. I'm
not sure I want to deal with the hassles of trying to remember what's
in C++11 versus what's in Lowest-Common-Denominator-Compiler.
I can already see a feature I'd like to use that didn't make it into
icpc 13, and three features that aren't even in icpc 14.
I could probably be talked into us supporting the intersection of
"stuff in C++11" and "stuff in a single broken compiler, X", where X
is something I can get auto-testing in buildbot, preferably icpc 11.1,
12.1, or 13.1. But then everyone with older pgc++ or other "not quite
C++11 compatible" compilers will be gambling.