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 this table for a list of currently supported versions that were chosen based on the policy described in this document.
1. 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.
- We will support releases of the following Linux distributions until the
vendor drops support (note: these were chosen
based on their popularity and/or their
availability on Google Compute Engine):
- Ubuntu LTS
- We will support Windows
- We will support macOS
- We will build using the newest Xcode available
- We will support back to the oldest macOS target platform needed by Chrome
- We will support iOS
- We will build using the newest Xcode available
- We will support back to the oldest iOS target platform that has a
- Ex: With Xcode 13.2, the oldest simulator is for iOS 12.4
- We will support Android
- We will build using the newest Android NDK available and target its lowest supported API level (example meta/platforms.json)
- We will support new releases of other supported operating systems on our normal release schedule within 90 days.
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 a 2021 JetBrains survey.
- We do not support any compiler that is EOL as defined by the vendor.
- 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-7 on RHEL/CentOS 7)
- We support Apple Clang on our supported macOS/iOS versions.
- We support MSVC on our supported Windows versions.
- MSVC releases aren't closely tied to Windows OS versions, so we explicitly choose and agree on which versions we support
For example, the above criteria and the table of default compiler versions (shown below) would result in the following supported compilers:
- GCC >= 6.3.0
- Clang >= 6.0.0
- Apple Clang >= 12 (by way of the latest Xcode version; see https://en.wikipedia.org/wiki/Xcode#Toolchain_versions
- MSVC >= 2017
3. Build Systems
There's no standard build system for C++. According to external 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 native tools like MSVC and Xcode.
- 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 —
- Support the two most recent LTS versions.
- For example, as of Spring 2022 we will support the 5.0 LTS and 4.0 LTS
- 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 Spring 2022 the oldest supported CMake would be 3.7
- Installs of our LTS releases should include the necessary
- It's fine (and likely) if even non-LTS releases support this too
4. 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.
Since C++ language standards are never formally deprecated or EOL'd, we'll
evolve our support and drop old versions based on time and our supported
- 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
- 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.
For example, as of Spring 2022 all the supported compilers default to C++ >= 14, therefore this is the minimum C++ version we support.