[DEPRECATION] Drop C++11 support

[esigo]

Following November 30, 2022 SIG meeting, as gRPC and Prometheus require >C++14 and Gtest, abseil will not support C++11 with their next release; it becomes more challenging for us to support C++11.
This will require us to have multiple combination of dependencies tests on our CI.

I suggest to announce the drop of support as soon as we can, and drop the support in 6 months after the announcement.

This issue is for collecting feedback from the users.

[esigo]

Hi @owent, it would be great to have your feedback here. Thanks

[owent]

Hi @owent, it would be great to have your feedback here. Thanks

It would be great if otel-cpp just remove the CI jobs but do not use new features of C++14, I can maintain the gRPC and protobuf in my internal version.

[lalitb]

Plan to announce the deprecation during next release (tentative).

[ThomsonTan]

Hi @owent, it would be great to have your feedback here. Thanks

It would be great if otel-cpp just remove the CI jobs but do not use new features of C++14, I can maintain the gRPC and protobuf in my internal version.

@owent do you need some longer time to migrate to C++14, or no existing plan from your side and will stay on C++ 11 for a while?

[owent]

Hi @owent, it would be great to have your feedback here. Thanks

It would be great if otel-cpp just remove the CI jobs but do not use new features of C++14, I can maintain the gRPC and protobuf in my internal version.

@owent do you need some longer time to migrate to C++14, or no existing plan from your side and will stay on C++ 11 for a while?

We still have some old systems use gcc 4.8(with a lot of binary/prebuilt dependencies and maybe can not upgrade in at least one or two years), it only support part of C++14.
It's fine by me if we just remove the ci jobs and avoid to use the new features gcc 4.8 do not support.I have another tool repo (http://github.com/atframework/cmake-toolset) which will check the compatibility and fix any problem when I find in the future.

[malkia]

I only hope make_unique and make_shared would slowly get into use :)

[owent]

I only hope make_unique and make_shared would slowly get into use :)

I think we can add nostd::make_unique and nostd::make_shared to replace the direct usage of std::make_unique and std::make_shared.Just like promethues.

[github-actions]

This issue was marked as stale due to lack of activity.