Carbon Components Angular: the support matrix stops at v5 while v6 sits in rc

The matrix has no v6 column and the newest tag is a v6 rc

The Angular support matrix has three columns, headed v3, v4 and v5, and rows for Angular 6 through 21. The release history has already moved past that. The three newest tags are v6.0.0-rc.24 on 2026-08-10, v5.72.2 on 2026-06-30 and v5.72.1 on 2026-06-25, so a v6 line exists as a release candidate while the table that tells you which Carbon version pairs with your Angular major stops at v5.

The publishing setup explains the split. Releases come from semantic-release, and the configuration routes the `master` branch to the `latest` channel, a `next` branch to the `next` channel with a prerelease identifier of `rc`, and three long-lived branches to their own channels. So rc.24 is what the `next` line produces, and v5.72.2 is what the stable line produced last.

The default branch is `master`, the license is Apache-2.0, and the last push is 2026-09-11.

Angular 9 through 13 sit in a v4-only gap

Reading the matrix row by row makes the coverage uneven. Angular 6 is v3 only. Angular 7 and 8 are v3 and v4, with v5 marked unsupported. Angular 9, 10, 11, 12 and 13 are v4 only, every one of them with v5 marked unsupported. Angular 14 and 15 pick up v5. Angular 16, 17, 18, 19, 20 and 21 are v5 only, since v3 and v4 are both marked unsupported from 16 upward.

So the v5 line starts at Angular 14, and the five Angular majors from 9 to 13 are the group with no path to it. That block is also the only place where a supported Angular major has exactly one Carbon option rather than a migration choice, which matters when a team plans an Angular upgrade and expects the component library to come along.

The v3 column stops at Angular 8 and the v4 column stops at Angular 15, so each Carbon line has a stated ceiling as well as a floor.

The policy sentence covers two versions, the table covers four

The out-of-support note reads that the project plans to support its latest and previous release, and that beyond that there are no guarantees of continued support, naming v1 and v2 as included in that beyond. The version table beside it gives v3 and v4 community support and v5 both community and active support, which is four versions with some form of support against a policy sentence about two.

The two support levels are defined rather than implied. Community support means the project depends mainly on community issue reports and contributions, that such a version leans on contributions, and that small fixes will be backported when applicable. Active support means actively maintaining and updating with new features, new components and bug fixes, and keeping it compatible with the Carbon Design System and the latest Angular versions.

Read that way, v3 and v4 receive backported small fixes when someone contributes them, while v5 is the line that receives features. Anyone still on v3 or v4 is being told to expect fixes on request rather than a stream of them.

A branch named v9 publishes the 2.x line and v10 publishes 4.x

The release configuration names five branches, and three of them do not match the versions they publish:

"branches": [
  { "name": "master", "channel": "latest" },
  { "name": "next", "channel": "next", "prerelease": "rc" },
  { "name": "v3", "channel": "carbon-v3", "range": "3.x" },
  { "name": "v9", "channel": "carbon-v9", "range": "2.X" },
  { "name": "v10", "channel": "carbon-v10", "range": "4.x" }
]

A branch called v9 ships the 2.x line and a branch called v10 ships 4.x, while the branch that matches its range is the one called v3. The branch names are historical rather than descriptive, which means the name of a maintenance branch tells you nothing about the version a consumer installs. The channels do carry the information, since each has a carbon-prefixed name of its own, and the tag format is `v${version}` with the package root at `dist`.

One detail is easy to miss: the v9 range is written `2.X` with an uppercase X while the others are lowercase, which is the kind of thing a range matcher can disagree about.

postinstall runs ibmtelemetry and prepare installs husky hooks

Two scripts run on install rather than on demand:

"prepare": "husky install",
"postinstall": "ibmtelemetry --config=telemetry.yml"

The telemetry command reads `telemetry.yml`, a file that sits at the root of the repository next to `angular.json` and `gulpfile.js`. So installing the package from a registry executes a telemetry binary configured by a file the consumer never sees, and installing from a git dependency additionally installs husky hooks into that checkout.

The documentation does not mention either script. There is no section on telemetry, no statement of what is collected, and no opt-out flag, and the only evidence in the repository is the config filename and the script line. If your build environment blocks postinstall scripts, this is the reason the install will appear to do nothing useful, and the failure will not name the cause.

TSLint for code, Karma for tests, gulp in the build

The manifest's quality tooling is one generation behind the framework it supports. `lint` runs `tslint 'src/**/*.ts'` and `lint:fix` adds `--fix`, with `tslint.json` at the root, while the contributing guide tells you to follow the Angular style guide and to run `npm test` and `npm run lint` before opening a pull request. Tests run through `ng test --no-watch` with `ng test --watch` for the loop, and the root carries `karma.conf.js`, `karma-test-shim.js` and `test.ts`, so the suite is Karma-based rather than a newer runner.

The build is a shell script, `bash scripts/build.sh`, and the npm commands section says webpack, gulp and general build tasks are all run through npm scripts, with an explicit instruction never to install webpack or gulp globally. `gulpfile.js` is still at the root.

Around those sit `.travis.yml` next to a `.github/` directory, `commitlint.config.js`, `.husky/`, `.stylelintrc.yml`, `CODEOWNERS`, `.nvmrc` and an `integration/` directory. Several generations of tooling configuration are live at once.

The repository description is the guide's closing line

The repository description reads: An Angular implementation of the Carbon Design System for IBM, followed by Now we can run npm start and start building out our application. The second sentence is the last line of the getting started section, left in place as the project's summary, which is the kind of copy that survives long after the sentence meant anything in context.

The manifest has a smaller version of the same habit. Its version is `0.0.0` and its description is Next generation components, both of which are placeholders: semantic-release writes the real version at publish time, so 0.0.0 in the tree is expected, and the release tags confirm it, while the description field is simply never filled in. `main` points at `index.js` at the package root.

The pull request section carries one more placeholder that survived into the published page: a line reading link to code review checklist goes here, pointing at an empty anchor, sitting among real instructions about WIP prefixes, labels and issue-closing keywords.

Three files to touch before npm start does anything

The bootstrap is one install line and two file edits. The install pulls the library and its two style packages together:

$ npx @angular/cli new my-project --style=scss
$ cd my-project
$ npm i --save carbon-components-angular @carbon/styles @carbon/icons

Then `src/styles.scss` configures the Sass entry point, and the comments inside it carry two version facts: CSS Grid became the default grid system in v11, and the font path has to be written without a tilde, which the comment marks as required for vite on Angular 16 and later. That block sets `$use-flexbox-grid: true`, sets `$font-path: '@ibm/plex'`, pulls in `@carbon/styles`, and wraps `styles.theme(styles.$white)` around the `html` selector so the CSS variables land at the root.

The third edit is a type declaration, in any file with a `.d.ts` suffix in the source directory:

declare module '@carbon/icons/*';

The page is explicit that this is not the only way to bootstrap the library, but that `@angular/cli` with the `@carbon/styles` Sass is the recommended combination.

Editorial conclusion

carbon-components-angular is a mature library with a published support policy, a real contribution path and a version scheme you can decode, but its documentation and its release configuration have drifted apart. It suits a team on Angular 14 or newer that has standardised on Carbon and wants components that track the design system, and it does not suit a team that needs the newest Carbon release today, since v6 exists only as a release candidate and the matrix does not list it. Before you pin a version, read the matrix row for your Angular major, check whether the branch you are on publishes the line you expect, and decide what you want running on install given the postinstall telemetry command and the husky prepare hook.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes