1. はじめに
Ubuntu LTS 26.04 や Linux Kernel 7.0 がリリースされましたが、Zephyr v4.4 も同じ月にリリース！ということで、Zephyr のリリースサイクルについて触れていこうかと思い記事にしました。
Zephyr も Linux kernel や Ubuntu と同様にメジャーバージョン、マイナーバージョンがあり、LTS を設けるなど製品への採用を意識したリリースサイクルを採用しています。
公式のページは以下にあり、これに沿って Zephyr 本体の開発側の動きを紹介しつつ、Zephyr を製品に採用するエンドユーザー開発者の視点でも整理できればと思います。
Zephyr を量産品などで採用する際、公式リポジトリの追従やメンテンナンスの頻度・タイミングなどを検討する上での一助になれば幸いです。
2. バージョン毎の期間
Zephyr のバージョンアップは、v3から2026年4月現在は、機能単位ではなく約6ヶ月周期という期間で区切られています。
その内訳として、約5ヶ月の開発期間、数週間の安定化やバグ修正、ドキュメント改善などに充てられていて、必要に応じて RC(Release Candidate)-4 〜 6 ぐらいまで続く、という流れ。
| Stage | Period | Target |
|---|---|---|
| Development | 約5ヶ月 | 開発中のブランチからメインブランチにマージ |
| Stabilisation | 数週間 | 安定化、バグ修正、ドキュメントの改善、テスト |
3. リリースまでのおおまかな流れ
約6ヶ月を細分化したタイムラインは以下のようになっています。
| 時間軸 | 説明 |
|---|---|
| 5ヶ月前 | リリースの目標、リリース日の確定や担当者の割当など |
| 7週間前 | 機能毎の目標マイルスートンを確定 |
| 5週間前 | リリース責任者が、凍結とリリース時期を共有 |
| 4週間前 | 先述の時期をリマインダー通知 |
| 3週間前 | RC1 として固めて新機能追加を停止、安定性の向上やバグ修正、ドキュメントやテストを更新のみ受理 |
| 2週間前 | RC2 として固めてRC1の内容を継続 |
| 1週間前 | RC3 以降は重大なバグ修正、ドキュメント改善、リリースノートのみ受理 |
| 0週間前 | 正式版リリース |
6カ月のうち最後の3週間で新機能追加を停止・凍結してリリース準備に入る、ということですね。
4. LTS について
冒頭でも記載した通り Zephyr にも LTS があり、基本的に最終マイナーバージョンが LTS になる傾向があるようです。2026年4月30日現時点で LTS は以下の通り。
| LTS バージョン | メンテナンス期間 |
|---|---|
| v1.14.3 | 2021年11月16日終了 (EOL) |
| v2.7.6-10 | 2024年3月2日終了 (EOL) |
| v3.7.2 | 2024年7月26日 〜 2027年1月26日 |
| v4.6 (未リリース) | 2027年4月頃 〜 2029年10月頃 |
最新の詳細な日程は以下に記載されています。
5. 実際の採用方法や運用方針について
私自身もまだ LTS が EOL になった場合の運用を実務で経験していないのですが、v1 から触り続けている経験として、およその傾向とそれに対する考えを記しておきます。
5.1. LTS の空白期間
前項のメンテナンス実績から、LTS は空白期間がほぼ発生しないように計画されていることがわかります(例：v2 LTS 2024年3月2日まで、v3 LTS は 2024年7月26日リリース)。
5.2. リリースサイクルについて
Zephyr のリリースサイクルは約6ヶ月毎に区切ったリリースで、機能単位のリリースではありません。これは Ubuntu などのディストリビューションが採用している方式と同じです。
(Linux kernel 自体も、昔は機能単位でリリースしていましが、v2.6以降でゆるやかな時間軸を採用しています)
5.3. Zephyr 採用側の運用方針に対する考え方
LTS の空白期間はほぼ発生しないため、次期リリースされる毎にメジャーバージョンアップを行えば良い・・・と考えてしまうのですが、Zephyr の開発スピードはかなり早く、v2 LTS から v3 LTS はかなり差異があり、同様に v3 LTS から v4 LTS の差分も大きい事が想定されます。
また、Zephyr は機能単位のリリースではありません。そのため、特定の機能だけを追従して、それを cherry-pick などで部分的に取り込むというのも正直難しいです。
これらの傾向から、LTS が EOL した際、次のメジャーバージョンの導入はほぼ下回りを刷新する想定でリソース確保した方が良い、というのが私の考えです。
もちろん、こまめに新しいバージョンを取り込むのも一つの選択肢ですが、その運用だと『LTSとは…？』になりますので、それを踏まえて方針を決める必要があります。
6. まとめ
製品への採用に応えるため、長期メンテナンス対象である LTS を用意していることは、量産開発を行う側にとっては、かなり好感が持てる対応だと思います。
一方で、非常に開発スピードが早く、ディレクトリ構成などのアグレッシブな変更や、Zephyr の管轄外のベンダー側の変更(modules等)もあるため、
- その製品のサポート期間は LTS をまたぐ(約3年以上)のか
- LTS をまたぐ場合、公式リポジトリの追従やメンテナンス頻度はどの程度行うのか
について、Zephyr 採用する段階で予め方針を定めておいた方が良さそうです。
せっかくなので Zephyr v4.4.0 のリリースノートへのリンクも貼っておきます。
v4.4.0 に合わせて、Zephyr-SDK 側もついに v0.17.4 から v1.0.1 になったのが印象的ですね。