For others reference, this thread is a follow up to the discussion on this pull request:
It looks like I doubled with @wjwwood in our replies but this is similar but mostly new.
Although we drive the processof determining the REP targets at OSRF it’s an open community process that’s well circulated to the mailing lists and is open for contributions. Personally I’d love to blaze ahead and jump forward to the new standards. And many others here at OSRF also would love to do that too. However, we know that many in the community value stability and our goal is to best represent what we believe is best for the whole community.
If you review the discussion about how to pick the target platforms we considered many different options. There are good cases for both conservative and aggressive approaches however we eventually converged on the currently defined compromise.
The compromise selected allows many of the new features of the standard to be utilized. But prevents public API changes to the new standard for core packages so as not to make one packages changes force changes to other packages.
Part of being a core package in the ROS ecosystem is understanding that a lot of other developers depend on your APIs and any API change made at the core ripples across all the dependencies. There are many thousands of packages that depend on the API, and if you change the API in a non-backwards compatible manner it will force thousands of maintainers to respond immediately. We picked desktop-full as the target since it’s what most people consider the core packages relied upon by most of the community and thus are the packages we work really hard to remain stable.
What was particularly valuable about this compromise is that by not exposing c++11 in the headers we prevented a single packages from forcing all downstream packages from requiring a patch to their CMakeLists.txt before releasing. This is especially valuable as we know that this forced patch will no longer be needed once gcc6 is standard, and the changes to the CMakeLists.txt will no longer be needed. And as @wjwwood and @de-vri-es have pointed out if one package exports a compiler standard it may interfere with other packages choices of compiler.
When coordinating a large community it’s always true that some parts of the community will adopt new standards sooner than others. In this case we can consider making an exception to the rule and allow geometric_shapes to use c++11 in the headers. But we need to build community consensus since it will effect a large fraction of the community. The reason I suggested moving to this forum is to get a larger community discussion going and make sure that we’re understanding all the ramifications.