Foundational C++ Support Policy  |  Google Open Source (original) (raw)

Foundational C++ Support Policy

Stay organized with collections Save and categorize content based on your preferences.

Anything we consider to be supported means that we (theoretically) have an automated test for it. We say "theoretically", because the full support matrix for all combinations will be too big to fully test in practice. Practicality suggests a sparsely populated test matrix where we test every dimension in at least one configuration. For example, we may test the oldest version of GCC that we support and the newest, but not every version in between.

See theFoundational C++ Support tablefor a list of supported versions that were chosen based on the policy described in this document.

Operating Systems

We say that an operating system is supported if a user can reasonably get, install, and use our libraries using the tools and toolchains available for that operating system. In most cases this means the default toolchain for the platform.

Support Criteria

1. We will support releases of the following Linux distributions until thevendor drops support:
   1. Alpine
   2. CentOS
   3. Debian
   4. Fedora
   5. Rocky
   6. openSUSE
   7. Ubuntu LTS
      Some vendors have different support levels depending on the age of the product. They may start with a "Full" or "Active" support period, and eventually go to a "Extended" or "Security Only" support period. We only support our libraries with distributions still under "Active" or "Full" support.
2. We will support Windows
   1. We will build using the newest Windows server platform available
   2. We will support all the windows versions that Microsoft supports
      1. Windows client support
      2. Windows server support
3. We will support macOS
   1. We will build using the newest Xcode available
   2. We will support back to the oldest macOS target platform needed by Chrome
4. We will support iOS
   1. We will build using the newest Xcode available
   2. We will support back to the oldest iOS target platform that has a simulator
      1. Ex: With Xcode 13.2, the oldest simulator is for iOS 12.4
5. We will support Android
   1. We will build using the newest Android NDK available and target its lowest supported API level (examplemeta/platforms.json)
6. We will support new releases of other supported operating systems on our normal release schedule within 90 days.

CPU Architectures

We will support our code on the following CPU architectures:

• x86 (64- and 32-bit)
• AArch64
• iOS Emulator
• Android Emulator

Compilers

For supported compilers, we'll start by considering the default toolchains on each supported operating system (see above). We'll primarily focus on the most popular compilers in use, which are GCC, Clang, and MSVC according to a2021 JetBrains survey.

Support Criteria

1. We do not support any compiler that is EOL as defined by the vendor.
2. We support GCC and Clang on our supported Linux distros (see above). We support the version installed by default (e.g., apt install gcc), unless we've explicitly excluded support for that version because it doesn't support other required policies of ours (e.g., we agree to remove GCC 4.8 because of its incomplete C++11 support, as well as clang 3.x). If we cannot support the default version, we may instead support a newer version that's available from the vendor (e.g.,devtoolset-7on RHEL/CentOS 7)
3. We support Apple Clang on our supported macOS/iOS versions.
4. We support MSVC on our supported Windows versions.
   1. We support the MSVC versions that are in the Mainstream Support window as defined by Microsoft's Fixed Lifecycle Policy.

C Standard Library

We will support the C Standard Library implementation that is included with the operating systems we support. For operating systems where the C Standard Library is part of the toolchain, we will support the C Standard Library implementation included with the toolchain.

For each supported C library implementation, we will support the earliest version that ships with the operating systems and toolchains we support. This does not preclude supporting earlier versions.

In the interest of clarity, the list of C Standard Library implementations we support includes glibc, musl, Microsoft's CRT, and BSD libc.

Build Systems

There's no standard build system for C++. According toexternal developer surveys, CMake is the most popular with 55% usage, followed by autotools at 36%, and others dropping from there. Bazel has 1% usage externally, however, it's essential for at least one very important customer (i.e., Google).

Supporting multiple build systems has a real cost in increased testing, and manual work or tooling to automate said work. We want to support the fewest build systems necessary to accommodate the most important use cases, which seems to suggest supporting Bazel and CMake. CMake also integrates well with most IDEs and it knows how to use tools like MSVC and Xcode.

Support Criteria

• We will not support any build system that is EOL by the vendor.
• We will not support any build system that's not listed here.
• Bazel —
  • We will support the latest Bazel release (excluding pre-releases), which Bazel calls their Active release.
  • We will support the previous major version release for 12 months after it transitions into maintenance mode.
• CMake —
  • CMake < 3 is NOT supported (CMake 3.x started "modern CMake").
  • We support the oldest release that comes standard with a supported distro.
  • For example, as of Summer 2024 the oldest supported CMake would be 3.13
• Installs of our LTS releases should include the necessary pkgconfig files.
  • It's fine (and likely) if even non-LTS releases support this too.

C++ Language Standard

Maintaining support for any particular C++ standard forever (e.g., C++11) would make it difficult to accommodate newer language features that customers will increasingly come to expect. Eventually, Google's C++ libraries would appear outdated to customers wanting modern features.

Support Criteria

Since C++ language standards are never formally deprecated or EOL'd, we'll evolve our support and drop earlier versions based on time and our supported compilers' default --std=.

• We will support all modern C++ standards, from some oldest standard to the newest.
• We will drop support for our oldest supported C++ standard when one of the following happens:
  • All supported compilers* default to a newer version
  • When 10 years pass since the standard's release date
  • Example: In 2023, if all supported compilers use C++17 as their default, then we can drop support for C++14. Otherwise, we'll need to wait until 2024, which would be 10 years after C++14 was released.
• We will support the newest C++ language standard soon after the standard is published and compiler support is available.

* When considering compiler default versions, we're excluding Apple clang, which always defaults to C++98.

NOTE: dropping support for any given language version may not be immediately effective even if the preceding criteria are met. Always consult theFoundational C++ Support tablefor the latest official support.

Changelog