Releases
Zephyr project is provided as source code and build scripts for different target architectures and configurations, and not as a binary image. Updated versions of the Zephyr project are released approximately every six months.
All Zephyr project source code is maintained in a GitHub repository. In order to use a released version of the Zephyr project, it is recommended that you use West (Zephyr’s meta-tool) to Get Zephyr and install Python dependencies of the release you are interested in.
The technical documentation for current and past releases is available at https://docs.zephyrproject.org/ (use the version selector to select your release of interest).
Release Life Cycle and Maintenance
Major and Maintenance Release Cadence
The Zephyr Project delivers major releases using a six month cadence roughly timed each April and October of the year.
This timescale facilitates regular releases that have strong QA cycles while not overwhelming users with too many new releases.
The cadence is predictable and avoids many major holidays in various geographies.
The Zephyr project delivers maintenance releases on an unscheduled basis and are usually driven by the accumulation of enough significant fixes or enhancements to the associated major release.
The point release indicates a point in the major release branch where a full QA cycle and release process validates the content of the new branch.
Long Term Support and Maintenance
While stable releases are supported for the duration of 2 release cycles (roughly 1 year), some specific ones will be supported for a longer period by the Zephyr Project, and are called Long Term Support (LTS) releases.
A Zephyr Long Term Support (LTS) release is published every 2.5 to 3 years and is branched and maintained independently from the main tree for approximately 5 years after it was released.
This offers more stability to project users and leaves more time to upgrade to the following LTS release.
Transitioning to the new Release Cadence
The transition to the new release cadence will begin in 2026. Zephyr 4.4 is scheduled for release in April 2026, and subsequent releases will occur every six months.
The projected timeline for upcoming releases is as follows:
Release |
Planned Date |
Notes |
|---|---|---|
4.4 |
April 2026 |
|
4.5 |
October 2026 |
|
4.6 |
April 2027 |
LTS4 |
5.0 |
October 2027 |
Start of 5.x cycle |
5.1 |
April 2028 |
|
5.2 |
October 2028 |
|
5.3 |
April 2029 |
|
5.4 |
October 2029 |
LTS5 |
Starting with the 5.x release cycle, all releases will follow the new six-month cadence from the beginning.
Security Fixes
Each security issue fixed within Zephyr is backported or submitted to the following releases:
Currently supported Long Term Support (LTS) release.
The most recent two releases.
For more information, see Security Vulnerability Reporting.
Supported Releases
Release |
Release date |
EOL |
|---|---|---|
2025-07-18 |
2026-03-20 |
|
2025-03-07 |
2025-11-14 |
|
2024-07-26 |
2029-07-27 |
Previous LTS
Release |
EOL |
|---|---|
2025-01-26 |
|
2022-01-01 |
Release Notes
Release notes contain a list of changes that have been made to the different areas of the project during the development cycle of the release. Changes that require the user to modify their own application to support the new release may be mentioned in the release notes, but the details regarding what needs to be changed are to be detailed in the release’s migration guide.
Updates to the release notes post release cycle is permitted but limited to style, typographical fixes and to upmerge the notes from maintenance release branches with the sole purpose of keeping the latest documentation consistent with the changes in the project.
Migration Guides
Zephyr provides migration guides for all major releases, in order to assist users transition from the previous release.
As mentioned in the previous section, changes in the code that require an action (i.e. a modification of the source code or configuration files) on the part of the user in order to keep the existing behavior of their application belong in in the migration guide. This includes:
Breaking API changes
Deprecations
Devicetree or Kconfig changes that affect the user (changes to defaults, renames, etc)
Treewide changes that have an effect (e.g. changing the include path or defaulting to a different C standard library)
Anything else that can affect the compilation or runtime behavior of an existing application
Each entry in the migration guide must include a brief explanation of the change as well as refer to the Pull Request that introduced it, in order for the user to be able to understand the context of the change.
End-of-life Releases
Release notes and migration guides for end-of-life releases of Zephyr RTOS can be accessed here.