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.
This all sounds great. Just to be clear, we're talking 0.9.3 this week, then 1.0-rc1 ASAP after we go through and shred deprecated stuff? My "warnings fixes" branch might be worth merging into the latter too. > 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. We've started doing something like this already, no? Each release tends to have one or two "whoops" entries in the major.minor.subminor.whoops numbering conventions. Or are you thinking of keeping 1.0 alive well after the next official 1.x release? I guess that might not be much more work? Instead of backporting major bug fixes to the previous stable release, we'd backport to both the previous stable release and the 1.0.x branch? But right now we never backport minor bug fixes, for bugs of the kind that nobody would be likely to trigger in the few months before the next official release. If we have a bugfixes-only branch then we no longer have that leeway. > New development could occur on a master requiring C++11, unless > there is a consensus otherwise. It's 2014 already, and a good > quorum of C++11 features are implemented in pretty much all relevant > compilers. 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. https://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-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. --- Roy ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
