mention CB3 and gcc 7

Author: jaimergp

community/history.md

@@ -53,7 +53,9 @@ It's a little strange to describe Continuum's history here, but the company hist
 
 In 2016, Rich Signell at USGS connected Filipe and Phil with Travis Oliphant at Continuum, who assigned Michael Sarahan to be Continuum's representative in `conda-forge`. Ray Donnelly ([@mingwandroid](https://github.com/mingwandroid)) joined the team at Continuum soon afterwards, bringing extensive experience in package managers and toolchains from his involvement in the MSYS2 project. There was a period of time where conda-forge and Continuum worked together closely, with conda-forge relying on Continuum to supply several core libraries. In its infancy, the `conda-forge` channel had far fewer packages than the `defaults` channel. conda-forge's reliance on `defaults` was partly to lower conda-forge's maintenance burden and reduce duplicate work, but it also helped keep mixtures of conda-forge and `defaults` channel packages working by reducing possibility of divergence. Just as there were binary compatibility issues with mixing packages from among the many Binstar channels, mixing packages from `defaults` with `conda-forge` could be fragile and frustrating.
 
-Around this point in time, [GCC 5 arrived][gcc-5] with a breaking change in `libstdc++`. These changes, among other compiler updates, began to make the CentOS 5 toolchain troublesome. Cutting edge packages, such as the nascent TensorFlow project, required cumbersome patching to work with the older toolchain, if they worked at all. There was strong pressure from the community to update the ecosystem (i.e. the toolchain, and implicitly everything built with it). There were two prevailing options. One was Red Hat's `devtoolset`. This used an older GCC version which statically linked the newer `libstdc++` parts into binaries, so that `libstdc++` updates were not necessary on end user systems. The other was to build GCC ourselves, and to ship the newer `libstdc++` library as a conda package. This was a community decision, and it was split roughly down the middle. In the end, the community decided to take the latter route, for the sake of greater control over updating to the latest toolchains, instead of having to rely on Red Hat. One major advantage of providing our own toolchain was that we could provide the toolchain as a conda package instead of a system dependency, so we could now express toolchain requirements in our recipes and have better control over compiler flags and behavior.
+
+The result of this overhaul crystallized in the `compiler(...)` Jinja function in `conda-build` 3.x and the publication of the GCC 7 toolchain built from source in `defaults` [^anaconda-compilers].
+
 
 Here around 2017, Continuum renamed itself to Anaconda, so let's switch those names from here out.