Yocto Project End of Life (EOL) Dates and End of Support (EOS) Dates

Planning your next build? This Yocto Project end of life guide shows which releases still get fixes and which are already unsupported. The Yocto Project is a Linux Foundation open source project for building custom Linux images for embedded and IoT devices, independent of the hardware architecture, and each Yocto EOL date below comes from its published release pages. In short, only the LTS series and the newest stable series still get fixes.

Yocto Project End of Life Dates for Every Release

The table lists the Yocto Project releases from Warrior onward with each name, version, release month and current status. Any row marked EOL is unsupported, so it no longer receives fixes. Every Yocto Project version links to its release notes where one exists, and these Yocto Project releases all build embedded Linux images the same way.

Garburn 6.2 is in active development, with a release planned for April 2027. Check the release calendar and the release timeline before you commit to a series, then download a current one. You can also download older tarballs from the same page, but availability is not support: running an unsupported release in production means you carry every Linux kernel and userspace vulnerability yourself, and the Yocto Project will not download fixes into it.

Release Process: Major Release Cadence and EOL Timing

The project ships a major release about every six months, roughly each April and October. This six month cadence keeps QA strong without flooding developers with versions. Between majors, minor releases arrive on an unscheduled basis once enough fixes pile up, and each of these point releases, such as 5.0.20 passes a full QA cycle.

Each development cycle tags three milestone builds, then enters feature freeze, when the master branch accepts only fixes and minor core upgrades, and testing and quality assurance follows before the final tag. Under the stable release process, a regular stable release is maintained for about seven months, which is why a non-LTS version reaches EOL so quickly. Stable releases from the Yocto Project therefore come and go faster than most Linux distributions.

Codename and Release Date Conventions

Each series gets a name taken from mountains and passes in Cumbria, England, because a number like 6.1 can clash with a layer or company versioning scheme. The name is how you find a series in the EOL table above: branches sharing a name stay compatible, so check compatibility by name in your layers before you compare any release date with an EOL date.

Long Term Support (LTS) Releases and Their Support Level

A stable release is covered for seven months, while a long term support series is maintained for years, so your support level depends on the series you pick. LTS releases began with Dunfell 3.1 in April 2020, first promised for two years and later extended to four years. A new LTS release now arrives every two years and is supported for four years, leaving time to migrate to the next one.

The LTS series still inside their windows are Wrynose 6.0, which runs until April 2030, and Scarthgap 5.0, which runs until April 2028. Kirkstone 4.0, the previous LTS, reached its EOL in April 2026. Each LTS series keeps its Linux kernel and core recipes patched, so a kernel update lands without a new major version. When a serious issue appears, fixes go to the current stable branches and to every LTS release still inside its window, but older versions past EOL receive nothing.

Release Policy: What Gets Backported Before EOL

Once a release ships, the project assigns a maintainer who watches nominated patches and can backport or reject each fix, which is routine backporting work. Only changes already accepted on master are considered, and the patch acceptance rules are strict. Only these reach a release before its EOL: security fixes, CVE fixes and bug fixes are acceptable, while new features, general version upgrades, ABI or API breakage and metadata refactoring are not. A generic recipe upgrade is therefore unlikely to reach a stable branch, and exceptions need Technical Steering Committee approval.

Stable Point Release Upgrades

Some upstream projects keep branches that collect only bug fixes and security patches. For recipes tracking such an upstream, setting UPSTREAM_STABLE_RELEASE_REGEX lets the project bump packages from, say, 1.0.2 to 1.0.3 instead of backporting individual patches, which suits each recipe that follows a clean upstream. The regex filters version checks so only upstream versions inside the same stable series count as candidates.

What Happens to a Version After Its EOL Date

After the stable window closes, a release becomes unsupported unless a volunteer steps in. It then enters end-of-life status: no new point release, no CVE fixes, and no QA on newer host distributions. Your Linux build system keeps working (BitBake, a Python build engine, still runs), but each cross compilation toolchain, SDK and QEMU test image built on it stops improving, and a stale kernel is the usual first casualty. You can still download the source, yet embedded products on it ship with known holes. Run bitbake -e | grep DISTRO_VERSION to confirm which version you build today, then plan an upgrade and download a current LTS series.

Maintenance Window and Community Support

When the maintenance window ends, a release may continue under community support if a community maintainer steps up. This support is best-effort, and testing usually does not cover every platform the release first supported. If no volunteer appears, or the post goes vacant for two months, the release is declared end of life for good.

Governance and Maintainers Behind Each EOL Date

Richard Purdie is the Yocto Project architect, and a small group of maintainers each own a release series, such as Yoann Congal for the current LTS series. These maintainers, working with the community maintainer process, decide when a series reaches EOL: once nobody keeps a series patched, its EOL date is set. They coordinate the Poky reference distribution, BitBake and OpenEmbedded-Core (OE-Core) with the OpenEmbedded project, which shares maintenance of the core metadata. Several Linux distributions build on this tooling, and the git repository and documentation keep every archived series available after it stops receiving fixes. The Linux Foundation hosts the Yocto Project, and its Linux kernel work flows upstream.