meta-ros publishes eleven layers, but its newest tag is from 2015

Eleven layer directories, and two the matrix never mentions

The repository root is a directory of layers, and counting them tells you more than the documentation does.

There are eleven. One is `meta-ros-common`, which holds what every distribution shares. One pair is ROS 1: `meta-ros1` and `meta-ros1-noetic`. Then a `meta-ros2` base directory and five distro directories under it, for rolling, Humble, Jazzy, Kilted, and Lyrical. And two that belong to no column of the support table at all, `meta-spaceros` and `meta-spaceros-jazzy`.

That last pair is the interesting gap. The supported combinations table names Yocto releases on one axis and ROS 2 distros on the other, and SpaceROS appears on neither axis. Yet two directories exist for it in the root, maintained alongside everything else. So there is a layer set in active development whose support status is undefined by the policy the same repository publishes.

The ROS 1 directories are the other thing to notice. The table has no ROS 1 column at all, and the declared migration in the project description is layers for ROS 1 and ROS 2. So the ROS 1 layers are being carried without appearing in the support matrix, which by the stated rule, that releases and distros not shown can be presumed unsupported, is the weakest position in the repository.

Underneath the layers sits a `scripts/` directory and a small amount of root configuration.

The support matrix is a grid of end of life dates

The central document is a table of dates rather than a table of features, and reading it as a grid tells you what to build against.

ROS 2 occupies the columns: Rolling with no date, then Humble as an LTS supported to May 2027, Jazzy as an LTS to May 2029, Kilted to November 2026, and Lyrical as an LTS to May 2031.

Yocto occupies the rows. Wrynose, marked LTS, runs to April 2030. Scarthgap, also LTS, runs to April 2028. And three rows are struck through entirely: Whinlatter at April 2026, Walnascar at November 2025, and Styhead at May 2025. The strikethrough is the EOL marker, and it covers every column in the row rather than individual cells, which means a Yocto release reaches end of life for all distros simultaneously.

The dates are not all the same within a row. Under Scarthgap, for instance, Humble is listed to May 2027 while Kilted is only to December 2026, because the constraint comes from whichever side runs out first. That is the mechanism the table encodes: a combination lives until the earlier of its two end of life dates.

The nearest deadline visible is Kilted at November 2026, roughly a month and a half after this snapshot. The rule that closes the table is explicit: releases and distros not shown can be presumed unsupported.

Four support levels, one of which still receives commits

The second table defines four values, and the definitions are more useful than the labels because they say what will actually happen to your build.

Full means the configuration is fully supported.

Unsupported does not mean ignored. Such a configuration is never built, and is only updated to fix breaking changes introduced upstream. The two examples given are exactly the ones that break unattended BitBake includes: a component repository renaming its default branch, and a fetch protocol needing to move from git to https. So an unsupported layer still gets commits when the world moves under it, and nothing else.

Best effort means the configuration has reached end of life, on either the ROS distro side or the OpenEmbedded release series side. The commitment is weakened to a best effort at having all its packages build. That is a notably weaker promise than a build failure being fixed, because the configuration is already outside its lifecycle.

Contrib means the configuration has been contributed and is not built at all. Nothing is compiled, so nothing can be verified.

Read together, the four values describe three kinds of dead configuration and one live one. A full configuration is built and checked. A contrib one is inert. And the two in between differ only in whether anyone is still attempting a build, which is the distinction that decides whether you will find out about breakage yourself or be told.

Getting started names a release the support table dropped

The quick start is one sentence and it points at a pairing you have to reconcile with the matrix.

The recommendation is to build the combination of Kirkstone with Humble, described as the easiest way to get started with ROS under OpenEmbedded. The mechanism is the kas tool, which clones the necessary git repositories and kicks off the build, with the instructions living in the repository on the build branch rather than in the main documentation.

Kirkstone does not appear in the support combinations table. The rows there begin at Scarthgap and go up through Whinlatter, Wrynose, and Rolling, and Styhead, Walnascar, and Whinlatter are the struck-through ones. So the pair the project tells you to start with sits outside the grid the same project publishes, which means the easiest starting point and the supported combinations are not the same thing.

Whether that is a problem depends on what you are doing. If you want a working image this week, Kirkstone with Humble is a configuration people have built many times. If you want one that will keep building as Yocto moves, the matrix is the document to read instead, and the closest LTS pairing still inside the grid is the one to choose.

The two documents disagree quietly, with no warning on either side.

Generated recipes and the appends that correct them

The layer contents are split along one line, and understanding it explains how the project can support a dozen distro and release combinations without maintaining them by hand.

Recipes are generated. They come from the superflore tool and they land in directories whose names start with `recipes-`. The generation scheme has its own wiki page describing what was done and what the current milestones are.

Corrections are separate. When a change has to be made against a generated recipe, a bbappend file is written, and those live in their own directory. So nothing edits a generated file in place, which is what makes regeneration safe: the tool can overwrite the recipes and the appends survive.

Above that sits one directory per distro inside each branch, containing the BitBake configuration that describes the distro. That configuration is where you find out which packages from ROS may be built at all, which is the policy decision rather than the build recipe.

And one layer is shared by everything. `meta-ros-common` carries the recipes common to all ROS distributions, which is described as third party libraries and tools that ROS needs, plus the ROS specific image and package group recipes. So the split is shared third party content in one layer, distro policy in another, generated packages in another, and patches in a fourth.

The newest tag is from 2015 and the newest milestone from 2022

The version record of this project is disconnected from its development record, and the gap is large enough to mislead anyone who checks tags first.

There are three GitHub releases. They are version 0.2 and its two release candidates, `v0.2rc1` and `v0.2rc2`, published in April and May 2015. Nothing has been tagged that way since.

A separate mechanism exists and it also stopped. Milestone releases carry information on the wiki, follow the format of a branch name, a milestones directory, and a number, and the last official one was Milestone 17 on 2022-06-05. Milestones are described as providing updates for all supported combinations at once, which is the right granularity for a layer set, and there has not been one in four years.

Meanwhile the default branch is pushed regularly, with the last commit dated 2026-09-17, and the repository shows 489 stars, 286 forks, and 95 open issues.

That fork ratio is worth pausing on. At 286 forks against 489 stars, most of the community has cloned the repository into its own namespace rather than opening pull requests, which is normal for Yocto layers where a product team adds its own recipes. It also means the master branch, not the tags, is where other people's work actually is.

For planning purposes: track the branch for the Yocto release you are on, and ignore the release list entirely.

Branches split into linear, rebased, and build tool

The branch scheme is the part of this repository with the most moving pieces, and it exists because the same source tree has to serve several different update models.

The default branch follows the Yocto Project release series currently under development, so it is where new work lands.

Branches named after Yocto releases track updates through their support lifecycle. These have linear commit history, which is the property that matters: a maintained long term branch should be append only so that a bisect across months of commits behaves.

The `-next` branches hold commits that are pending merge into the corresponding unsuffixed branch. Their history may be rewritten, because patches get tested and revised before they land. That is the one place in the repository where history is mutable, and it is deliberate.

The `build` branch is a different kind of thing entirely. It holds the mcf tool, which creates an environment from configuration files, and those configuration files are kept in three directories named for the support levels already defined: files for the supported ones, files-contrib, and files-unsupported. So the tooling branch encodes the same four level policy as an on disk directory structure.

The original ROS 1 implementation from before all of this is still present on a `legacy` branch, kept rather than deleted.

Two origins, a Travis file, and a fortnightly meeting

The history section records a transfer and a port, and the root still carries one artifact from a much earlier era.

The original implementation of meta-ros for ROS 1 Indigo Igloo lived elsewhere, at the BMW Car IT repository, and was transferred into this repository on 2019-06-25.

The ROS 2 port was a separate effort. Erle Robotics undertook it, shared their work at their own meta-ros2 repository first, and then integrated it upstream. The project was subsequently converted to use recipes generated by superflore, which is the change that produced the current layout.

One root file does not belong to any of that. There is a `.travis.yml`, a configuration file for a continuous integration service that open source projects no longer run builds on. It has almost certainly not been executing for years, and it is the kind of file that survives because nothing deletes it.

The rest of the root is conventional: a COPYING.MIT file for the MIT licence, a CONTRIBUTING.md that points at ROS contribution policies rather than restating them, and a `.github/` directory.

Contributions are invited in four named forms, which is a useful signal about where the project's gaps are: report build errors, write documentation, add support for ROS packages that are currently skipped, and add build and run time tests for ROS packages. Two of those four are about adding coverage rather than adding features, which fits a project whose support levels are defined by what gets built.

The community side runs on the ROS Discourse forum's OpenEmbedded category and a bi-weekly working group with published minutes and open meeting invites.

Editorial conclusion

meta-ros suits anyone producing a custom Linux image for a robot and who would rather not vendor ROS packages by hand, and the support matrix with explicit end of life dates per combination is the document to read first, since it tells you which pairing is still being built and which is best effort. Three things to check before you pick a combination. Do not follow the getting started line without cross checking the matrix, because it names a Yocto release that the support table no longer lists. Do not treat the release tags as a version signal, because the newest is from 2015 and the newest milestone is from 2022 while the default branch is pushed weekly. And note that two layer directories in the repository root are not in the matrix at all, so if you want them you are outside the stated support policy and need to work out the maintenance story yourself.

Frequently asked questions

Official sources

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