https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Michael+OpdenackerYocto Project - User contributions [en]2026-04-20T15:37:06ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86628Releases2025-05-09T14:05:03Z<p>Michael Opdenacker: /* Release Activity */ Update Walnascar release date</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/dev/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
!Notes<br />
|-<br />
|Wrynose<br />
|6.0<br />
| April 2026<br />
|<br />
|Future<br />
|N/A<br />
|2.16<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|<br />
|-<br />
|Whinlatter<br />
|5.3<br />
| October 2025<br />
|<br />
|Future<br />
|N/A<br />
|2.14<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|Walnascar (aka Walna)<br />
|5.2<br />
| May 2025<br />
|<br />
|Support for 7 months (until November 2025)<br />
|N/A<br />
|2.12<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|-style="color: slategray;"<br />
|Styhead <br/>(like 'try head')<br />
|5.1<br />
| October 2024<br />
|5.1.4 (April 2025)<br />
|EOL<br />
|N/A<br />
|2.10<br />
|Steve Sakoman <steve@sakoman.com><br />
|<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
| 5.0.9 (May 2025)<br />
|Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Steve Sakoman <steve@sakoman.com><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|-style="color: slategray;"<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3.4 (April 2024)<br />
| EOL<br />
|N/A<br />
|2.6<br />
|Steve Sakoman <steve@sakoman.com><br />
|- style="color: slategray;"<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.4 (December 2023)<br />
| EOL<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.26 (April 2025)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.33 (May 2024)<br />
| EOL - LTS¹<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2017)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Workshop_Embedded_Recipes_2025&diff=86604Yocto Project Workshop Embedded Recipes 20252025-04-10T04:25:16Z<p>Michael Opdenacker: Initial version</p>
<hr />
<div>See https://www.yoctoproject.org/event/embedded-recipes-workshop-25/ for registration and call for participation links.<br />
<br />
=== Pitch your projects ===<br />
<br />
Take the opportunity to join the stage for up to 5 minutes and share what you're doing with Yocto - New recipes, new layers, new tooling, or just what you're trying to do and the challenges you're facing.<br />
<br />
To participate, add your name to the list below. Attach a short slide deck if you wish, or ask [[User:Michael Opdenacker|Michael Opdenacker]] to do it for you.<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
|- bgcolor="#c0e0e0"<br />
|- bgcolor="#c0e0e0"<br />
| align="center" | '''Presenter'''<br />
| align="center" | '''Pitch description''' <br />
| align="center" | '''Slides or link'''<br />
|- <br />
| Michael Opdenacker<br />
| Testing Yocto Security Features<br />
| <br />
|-<br />
| Josef Holzmayr<br />
| Getting More People Involved<br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&diff=86591Project Users2025-03-19T06:57:46Z<p>Michael Opdenacker: /* Products that use the Yocto Project */ Add missing parenthesis</p>
<hr />
<div>It's hard to know which companies or projects use the Yocto Project since there is no requirement to tell us. This list is here to informally collate the companies, projects and products that use the Yocto Project in some way. This helps the project since it means we can show at least some cross section of which companies are using it and how/where. There is more information about this here: https://lists.yoctoproject.org/g/yocto/topic/82722441<br />
<br />
= Companies using the Yocto Project =<br />
<br />
== Semiconductor Vendors ==<br />
* AMD (Platinum Member)<br />
* ARM (Platinum Member)<br />
* Intel (Platinum Member)<br />
* Microchip<br />
* NXP (Silver Member)<br />
* Qualcomm(Platinum Member)<br />
* Renesas (Gold Member)<br />
* STMicroelectronics (Silver Member)<br />
* Texas Instruments (Gold Member)<br />
* Xilinx (AMD Platinum Member)<br />
<br />
== Operating System Vendors ==<br />
* ENEA (Silver Member)<br />
* Linaro (Gold Member)<br />
* Lineo (Silver Member)<br />
* Mentor Graphics (Siemens Gold Member)<br />
* Microsoft (Platinum Member)<br />
* Montavista (Silver Member)<br />
* Wind River (Platinum Member)<br />
<br />
== Others ==<br />
* [https://3mdeb.com/ 3mdeb]<br />
* [https://alladin.at/ alladin-IT GmbH]<br />
* [https://www.ambu.com/ Ambu] (Endoscope video devices)<br />
* [https://www.arthrex.co.uk/ Arthrex] (Surgical video products)<br />
* Atlas Copco<br />
* AWS (Platinum Member)<br />
* [https://www.axis.com/ Axis Communications] (Silver Member)<br />
* [https://www.balena.io/ Balena]<br />
* [https://www.brose.com/ Brose]<br />
* BMW<br />
* BMW Car IT(Platinum Member)<br />
* [https://www.brightsign.biz/ BrightSign]<br />
* [https://www.bruker.com/ Bruker BioSpin GmbH]<br />
* [https://bootlin.com/ Bootlin (Silver Member)]<br />
* Cisco (Platinum Member)<br />
* CNH Industrial<br />
* Comcast (Platinum Member)<br />
* [https://www.cytera.bio/ Cytera] (via Belena)<br />
* Dell (Silver Member)<br />
* [https://www.denx.de/ DENX Software Engineering]<br />
* Dynamic Devices<br />
* Ekinops<br />
* [https://www.ericsson.com Ericsson]<br />
* Facebook (Meta)<br />
* [https://formlabs.com/ Formlabs]<br />
* Fujitsu<br />
* [https://www.gardena.com/ GARDENA] (Husqvarna Group)<br />
* [https://www.garmin.com/ Garmin] (Platinum Member)<br />
* General Electric<br />
* [https://genielifesciences.com/ Genie Life Sciences]<br />
* Gigaset Communications GmbH <br />
* [https://hillrom.com Hillrom]<br />
* [https://www.hanoverdisplays.com/ Hanover]<br />
* Juniper<br />
* [https://koansoftware.com/ KOAN sas]<br />
* Kodak<br />
* [https://www.korg.com/ Korg]<br />
* [https://lawo.com/ LAWO]<br />
* Lexmark<br />
* LG (Platinum Member)<br />
* [https://lightyear.one/ Lightyear]<br />
* National Instruments<br />
* [https://www.ovo.auto/ OVO Automotive]<br />
* [https://www.pengutronix.de/ Pengutronix]<br />
* [https://remarkable.com/ reMarkable]<br />
* [https://www.rethinkrobotics.com/ Rethink Robotics GmbH]<br />
* [https://rootcommit.com Root Commit]<br />
* [https://www.siemens.com/ Siemens] (Gold Member)<br />
* [https://www.smile.eu/en/offers/embedded-iot Smile ECS (Silver Member)]<br />
* Sonos<br />
* StreamUnlimited Engineering GmbH<br />
* [https://www.taitradio.com Tait Communications]<br />
* [https://www.witekio.com/values-expertise/ Witekio (Gold Member)]<br />
* [https://vecima.com Vecima Networks]<br />
* [https://www.veobot.com/ Veo Robotics]<br />
<br />
= Products that use the Yocto Project =<br />
<br />
* Amazon Eero<br />
* Amazon Echo Show 5 and Echo Hub<br />
* Ambu aview2 and abox2 <br />
* BMW cars<br />
* [https://www.cambridgeaudio.com/ Cambridge Audio] network streamers<br />
* Comcast set top boxes<br />
* [https://dasharo.com/ Dasharo]<br />
* [https://www.gardena.com/int/products/smart/ GARDENA smart garden] (The smart garden gateway runs Yocto/OpenEmbedded. Open source parts can be found [https://github.com/husqvarnagroup/smart-garden-gateway-public on GitHub.])<br />
* Some Garmin [https://www.garmin.com/marine/ Marine] Products<br />
* Gigaset DSPG-SOCs based products (e.g N870, N870 Integrator, Marine 2/3/4)<br />
* Go Pro (https://gopro.com/content/dam/help/open-source/2020-09-28%20-%20HERO9%20Black%20-GoPro%20Open%20Source%20Software%20Notice.pdf)<br />
* Ikea [https://www.ikea.com/gb/en/p/dirigera-hub-for-smart-products-white-smart-50503409/ DIRIGERA Smart Hub] ([https://github.com/ikea-oss-distributions/DIRIGERA-hub source])<br />
* [https://www.korg.com/uk/products/synthesizers/wavestate/ Korg Wavestate Synthesizer] ([https://github.com/korginc/wavestate_OSS sources])<br />
* LAWO [https://lawo.com/products/a__uhd-core/ A__UHD Core] [https://lawo.com/products/a__line/ A__ Line]<br />
* Lexmark Printers<br />
* LG webOS TVs<br />
* Lightyear 0 solar EV (Telematics Control Unit)<br />
* Mellanox Bluefield SmartNIC<br />
* [https://new.siemens.com/global/en/products/buildings.html Siemens Smart Infrastructure]: Products for sustainable, efficient and safe buildings<br />
* Sky Glass (clear from sources tarball [http://oss.sky.com/SkyHD/SkyGlass/skyglass_spk.tar.bz2])<br />
* [https://www.streamunlimited.com/hardware-modules/ StreamUnlimited hardware modules for voice assistants and connected speakers]<br />
* Vernier LabQuest<br />
* Teledyne FLIR thermal cameras (https://github.com/flir-cx/flir-yocto-documentation)<br />
* myVaillant smart home devices (https://opensource.myvaillant.com)<br />
* reMarkable E-ink tablets (https://developer.remarkable.com/documentation/software-stack)<br />
* Eight Sleep Pod ([https://blopker.com/writing/04-zerosleep-1/ from a rooting guide])<br />
<br />
= Projects that use the Yocto Project =<br />
<br />
* [https://asteroidos.org/ AsteroidOS]<br />
* [https://www.automotivelinux.org/ Automotive Grade Linux (AGL)]<br />
* [https://www.balena.io/ Balena]<br />
* Comcast RDK<br />
* [https://easyos.org/ EasyOS]<br />
* [https://github.com/oe-alliance Various Enigma2 based set-top boxes]<br />
* [https://www.webos-ports.org LuneOS]<br />
* Nvidia vibrante SDK [https://docs.nvidia.com/drive/archive/4.1.8.0L/nvoss_docs/index.html]<br />
* OpenBMC<br />
* [https://oryx-linux.org/ Oryx Linux]<br />
* [https://github.com/riscv/meta-riscv RISC-V]<br />
* [https://www.streamunlimited.com/stream-sdk/ StreamSDK for voice assistants and connected speakers]<br />
* Windows Subsystem Linux (v1+v2)<br />
* webOS<br />
* [https://www.webosose.org/ webOS OSE (Open Source Edition)]<br />
* [http://yoedistro.org The Yoe Distribution]</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&diff=86590Project Users2025-03-19T05:38:23Z<p>Michael Opdenacker: /* Others */ Add Root Commit</p>
<hr />
<div>It's hard to know which companies or projects use the Yocto Project since there is no requirement to tell us. This list is here to informally collate the companies, projects and products that use the Yocto Project in some way. This helps the project since it means we can show at least some cross section of which companies are using it and how/where. There is more information about this here: https://lists.yoctoproject.org/g/yocto/topic/82722441<br />
<br />
= Companies using the Yocto Project =<br />
<br />
== Semiconductor Vendors ==<br />
* AMD (Platinum Member)<br />
* ARM (Platinum Member)<br />
* Intel (Platinum Member)<br />
* Microchip<br />
* NXP (Silver Member)<br />
* Qualcomm(Platinum Member)<br />
* Renesas (Gold Member)<br />
* STMicroelectronics (Silver Member)<br />
* Texas Instruments (Gold Member)<br />
* Xilinx (AMD Platinum Member)<br />
<br />
== Operating System Vendors ==<br />
* ENEA (Silver Member)<br />
* Linaro (Gold Member)<br />
* Lineo (Silver Member)<br />
* Mentor Graphics (Siemens Gold Member)<br />
* Microsoft (Platinum Member)<br />
* Montavista (Silver Member)<br />
* Wind River (Platinum Member)<br />
<br />
== Others ==<br />
* [https://3mdeb.com/ 3mdeb]<br />
* [https://alladin.at/ alladin-IT GmbH]<br />
* [https://www.ambu.com/ Ambu] (Endoscope video devices)<br />
* [https://www.arthrex.co.uk/ Arthrex] (Surgical video products)<br />
* Atlas Copco<br />
* AWS (Platinum Member)<br />
* [https://www.axis.com/ Axis Communications] (Silver Member)<br />
* [https://www.balena.io/ Balena]<br />
* [https://www.brose.com/ Brose]<br />
* BMW<br />
* BMW Car IT(Platinum Member)<br />
* [https://www.brightsign.biz/ BrightSign]<br />
* [https://www.bruker.com/ Bruker BioSpin GmbH]<br />
* [https://bootlin.com/ Bootlin (Silver Member)]<br />
* Cisco (Platinum Member)<br />
* CNH Industrial<br />
* Comcast (Platinum Member)<br />
* [https://www.cytera.bio/ Cytera] (via Belena)<br />
* Dell (Silver Member)<br />
* [https://www.denx.de/ DENX Software Engineering]<br />
* Dynamic Devices<br />
* Ekinops<br />
* [https://www.ericsson.com Ericsson]<br />
* Facebook (Meta)<br />
* [https://formlabs.com/ Formlabs]<br />
* Fujitsu<br />
* [https://www.gardena.com/ GARDENA] (Husqvarna Group)<br />
* [https://www.garmin.com/ Garmin] (Platinum Member)<br />
* General Electric<br />
* [https://genielifesciences.com/ Genie Life Sciences]<br />
* Gigaset Communications GmbH <br />
* [https://hillrom.com Hillrom]<br />
* [https://www.hanoverdisplays.com/ Hanover]<br />
* Juniper<br />
* [https://koansoftware.com/ KOAN sas]<br />
* Kodak<br />
* [https://www.korg.com/ Korg]<br />
* [https://lawo.com/ LAWO]<br />
* Lexmark<br />
* LG (Platinum Member)<br />
* [https://lightyear.one/ Lightyear]<br />
* National Instruments<br />
* [https://www.ovo.auto/ OVO Automotive]<br />
* [https://www.pengutronix.de/ Pengutronix]<br />
* [https://remarkable.com/ reMarkable]<br />
* [https://www.rethinkrobotics.com/ Rethink Robotics GmbH]<br />
* [https://rootcommit.com Root Commit]<br />
* [https://www.siemens.com/ Siemens] (Gold Member)<br />
* [https://www.smile.eu/en/offers/embedded-iot Smile ECS (Silver Member)]<br />
* Sonos<br />
* StreamUnlimited Engineering GmbH<br />
* [https://www.taitradio.com Tait Communications]<br />
* [https://www.witekio.com/values-expertise/ Witekio (Gold Member)]<br />
* [https://vecima.com Vecima Networks]<br />
* [https://www.veobot.com/ Veo Robotics]<br />
<br />
= Products that use the Yocto Project =<br />
<br />
* Amazon Eero<br />
* Amazon Echo Show 5 and Echo Hub<br />
* Ambu aview2 and abox2 <br />
* BMW cars<br />
* [https://www.cambridgeaudio.com/ Cambridge Audio] network streamers<br />
* Comcast set top boxes<br />
* [https://dasharo.com/ Dasharo]<br />
* [https://www.gardena.com/int/products/smart/ GARDENA smart garden] (The smart garden gateway runs Yocto/OpenEmbedded. Open source parts can be found [https://github.com/husqvarnagroup/smart-garden-gateway-public on GitHub.])<br />
* Some Garmin [https://www.garmin.com/marine/ Marine] Products<br />
* Gigaset DSPG-SOCs based products (e.g N870, N870 Integrator, Marine 2/3/4)<br />
* Go Pro (https://gopro.com/content/dam/help/open-source/2020-09-28%20-%20HERO9%20Black%20-GoPro%20Open%20Source%20Software%20Notice.pdf)<br />
* Ikea [https://www.ikea.com/gb/en/p/dirigera-hub-for-smart-products-white-smart-50503409/ DIRIGERA Smart Hub] ([https://github.com/ikea-oss-distributions/DIRIGERA-hub source])<br />
* [https://www.korg.com/uk/products/synthesizers/wavestate/ Korg Wavestate Synthesizer] ([https://github.com/korginc/wavestate_OSS sources])<br />
* LAWO [https://lawo.com/products/a__uhd-core/ A__UHD Core] [https://lawo.com/products/a__line/ A__ Line]<br />
* Lexmark Printers<br />
* LG webOS TVs<br />
* Lightyear 0 solar EV (Telematics Control Unit)<br />
* Mellanox Bluefield SmartNIC<br />
* [https://new.siemens.com/global/en/products/buildings.html Siemens Smart Infrastructure]: Products for sustainable, efficient and safe buildings<br />
* Sky Glass (clear from sources tarball [http://oss.sky.com/SkyHD/SkyGlass/skyglass_spk.tar.bz2])<br />
* [https://www.streamunlimited.com/hardware-modules/ StreamUnlimited hardware modules for voice assistants and connected speakers]<br />
* Vernier LabQuest<br />
* Teledyne FLIR thermal cameras (https://github.com/flir-cx/flir-yocto-documentation)<br />
* myVaillant smart home devices (https://opensource.myvaillant.com)<br />
* reMarkable E-ink tablets (https://developer.remarkable.com/documentation/software-stack)<br />
* Eight Sleep Pod ([https://blopker.com/writing/04-zerosleep-1/ from a rooting guide]<br />
<br />
= Projects that use the Yocto Project =<br />
<br />
* [https://asteroidos.org/ AsteroidOS]<br />
* [https://www.automotivelinux.org/ Automotive Grade Linux (AGL)]<br />
* [https://www.balena.io/ Balena]<br />
* Comcast RDK<br />
* [https://easyos.org/ EasyOS]<br />
* [https://github.com/oe-alliance Various Enigma2 based set-top boxes]<br />
* [https://www.webos-ports.org LuneOS]<br />
* Nvidia vibrante SDK [https://docs.nvidia.com/drive/archive/4.1.8.0L/nvoss_docs/index.html]<br />
* OpenBMC<br />
* [https://oryx-linux.org/ Oryx Linux]<br />
* [https://github.com/riscv/meta-riscv RISC-V]<br />
* [https://www.streamunlimited.com/stream-sdk/ StreamSDK for voice assistants and connected speakers]<br />
* Windows Subsystem Linux (v1+v2)<br />
* webOS<br />
* [https://www.webosose.org/ webOS OSE (Open Source Edition)]<br />
* [http://yoedistro.org The Yoe Distribution]</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=User:Michael_Opdenacker&diff=86589User:Michael Opdenacker2025-03-19T05:36:44Z<p>Michael Opdenacker: Update my description</p>
<hr />
<div>Michael Opdenacker is the founder of [https://rootcommit.com Root Commit], a consulting and training company specializing in Free and Open Source Software for embedded systems, and a heavy user of the Yocto Project. Michael has made code and documentation contributions to the Yocto Project.</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86327Binary Distro Prototype2024-04-30T19:25:34Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />[https://lore.kernel.org/openembedded-core/20240429152221.3405405-1-michael.opdenacker@bootlin.com/T/#u An implementation as an oe-selftest] is available.<br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />[https://lore.kernel.org/bitbake-devel/20240430171512.936371-1-michael.opdenacker@bootlin.com/T/#t Patch series] submitted for the "passthrough" functionality, support for multiple upstream servers, and support for concurrent access from a read-write and a read-only server. This also adds bitbake-selftests to check all existing and new features and to detect future regressions. "oe-selftest - prservice" tests also pass provided an [https://lore.kernel.org/openembedded-core/20240429194656.655509-1-michael.opdenacker@bootlin.com/T/#u OE-core patch] is also merged.<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86326Binary Distro Prototype2024-04-30T17:26:54Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Code [https://lore.kernel.org/openembedded-core/20240429152221.3405405-1-michael.opdenacker@bootlin.com/T/#u implemented as an oe-selftest] has been submitted, taking the first reviews into account. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />[https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t Patch series] submitted for the "passthrough" functionality, support for multiple upstream servers, and support for concurrent access from a read-write and a read-only server. This also adds bitbake-selftests to check all existing and new features and to detect future regressions. "oe-selftest - prservice" tests also pass provided an [https://lore.kernel.org/openembedded-core/20240429194656.655509-1-michael.opdenacker@bootlin.com/T/#u OE-core patch] is also merged.<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86323Binary Distro Prototype2024-04-29T15:25:55Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Code [https://lore.kernel.org/openembedded-core/20240429152221.3405405-1-michael.opdenacker@bootlin.com/T/#u implemented as an oe-selftest] has been submitted, taking the first reviews into account. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Fourth [https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests are also implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes). A newer iteration, currently being tested, will also be posted by April 30, 2024, with support for multiple servers accessing the same database.<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86322Binary Distro Prototype2024-04-29T08:12:59Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />A [https://lore.kernel.org/openembedded-core/34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org/T/#t first version implemented as an oe-selftest] has been submitted. A new iteration will be posted by April 30, 2024, taking the reviews into account. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Fourth [https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests are also implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes). A newer iteration, currently being tested, will also be posted by April 30, 2024, with support for multiple servers accessing the same database.<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86321Binary Distro Prototype2024-04-26T08:00:39Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />A [https://lore.kernel.org/openembedded-core/34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org/T/#t first version implemented as an oe-selftest] has been submitted. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Fourth [https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests are also implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes).<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86320Binary Distro Prototype2024-04-26T07:59:50Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />A[https://lore.kernel.org/openembedded-core/34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org/T/#t first version implemented as an oe-selftest] has been submitted. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Fourth [https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t] patch series submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests are also implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes).<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86313Binary Distro Prototype2024-04-23T10:17:07Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing - A [https://lore.kernel.org/openembedded-core/20240413055421.210001-1-michael.opdenacker@bootlin.com/T/#u prototype based on the "testimage" class] has been submitted. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Fourth [https://lore.kernel.org/bitbake-devel/20240423093739.364140-1-michael.opdenacker@bootlin.com/T/#t] patch series submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests are also implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes).<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />. Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86312Binary Distro Prototype2024-04-22T14:36:47Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing - A [https://lore.kernel.org/openembedded-core/20240413055421.210001-1-michael.opdenacker@bootlin.com/T/#u prototype based on the "testimage" class] has been submitted. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Third [https://lore.kernel.org/bitbake-devel/20240412090234.4110915-1-michael.opdenacker@bootlin.com/T/#t] patch series submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. BitBake selftests have also been implemented for most of the code functionality (database, client, server, support for upstream server, read-only mode, "history" and "no history" modes). A fourth patch series is expected by Apr. 22 after real-life testing (generation of a full image, not only BitBake selftests).<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />. Possible thanks to the use of the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Proposal available on [[#Policies_and_Processes]], thanks to Richard and the TSC.<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86302Binary Distro Prototype2024-04-15T08:29:26Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing - A [https://lore.kernel.org/openembedded-core/20240413055421.210001-1-michael.opdenacker@bootlin.com/T/#u prototype based on the "testimage" class] has been submitted. <br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Third [https://lore.kernel.org/bitbake-devel/20240412090234.4110915-1-michael.opdenacker@bootlin.com/T/#t] patch series submitted for the "passthrough" functionality, with support for multiple upstream servers. The patches to modernize the existing PR server code have already been merged. The next step is to implement BitBake selftests to make sure all use cases are properly supported (in particular upstream server support and read-only mode) and bugs are found before merging the new feature.<br />
# Automated testing of the ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />To be started soon. Will use the PR server in read-only mode.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Draft version available on [[#Policies_and_Processes]], thanks to Richard and the TSC. Can this deliverable now be considered as "ready"?<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86301Releases2024-04-11T09:36:24Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.3.4 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/dev/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
!Notes<br />
|-<br />
|Styhead <br/>(like 'try head')<br />
|5.1<br />
| October 2024<br />
|<br />
|Future<br />
|N/A<br />
|2.10<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3.4 (April 2024)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Steve Sakoman <steve@sakoman.com><br />
|- style="color: slategray;"<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.4 (December 2023)<br />
| EOL<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.17 (March 2024)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.32 (Mar. 2024)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86296Binary Distro Prototype2024-04-08T08:04:58Z<p>Michael Opdenacker: /* Project status */ Update status</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing. I have a modified version of testimage.bbclass and an opkgfeed.py test that tests that an upgrade from a previously generated image succeeds with the feeds generated for the version being tested. Now need to explore the approach suggested by Richard, based directly on testimage.<br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />Second [https://lore.kernel.org/bitbake-devel/20240405164125.1652579-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality, with support for multiple upstream servers.<br />
# Automated testing of ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />To be started soon.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Draft version available on [[#Policies_and_Processes]], thanks to Richard and the TSC. Can this deliverable now be considered as "ready"?<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86292Binary Distro Prototype2024-04-02T15:44:23Z<p>Michael Opdenacker: /* Policies and Processes */ Add</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== PR server passthrough ==<br />
<br />
The goal of this part is to enable a local distribution to use packages from an "upstream" distribution, but customize specific ones so that the locally built packages have priority over the upstream ones.<br />
<br />
As for the Hash Equivalence server, we know have [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t a patchset] enabling a local PR server to contact an "upstream" server to compute the local PR value. Therefore, if an upstream package bears revision <x>, the local version of it can have revision <x>.<y>, having priority other the upstream one.<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing. I have a modified version of testimage.bbclass and an opkgfeed.py test that tests that an upgrade from a previously generated image succeeds with the feeds generated for the version being tested. Now need to explore the approach suggested by Richard, based directly on testimage.<br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />First [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality. What about the "hierarchical data" feature mentioned in the specifications?<br />
# Automated testing of ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />To be started soon.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Draft version available on [[#Policies_and_Processes]], thanks to Richard and the TSC. Can this deliverable now be considered as "ready"?<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86291Binary Distro Prototype2024-04-02T15:25:24Z<p>Michael Opdenacker: /* Achievements */ Add "Project status" section</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
Open questions:<br />
* When do we run updates? What does process look like?<br />
* How long are the feeds maintained?<br />
* How do we handle PR and PE changes wrt to the core layers?<br />
* Do we add a default user? How do we handle image passwords? root password?<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Process and policy for proposing adding new layers to the binary distro test artifacts process ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* In addition, layers must be well written and be targetting project best practices like reproducibility, no network access outside fetching so mirroring and licensing auditing works and not skipping QA tests without good reason.<br />
* Any dependency layers would already have to be included in the testing already or make a separate application for addition first.<br />
* The layer being added must be suitably generic with a clear need/usage of the components provided by the layer in the ecosystem<br />
* The layer maintainer must have a commitment to keeping recipe upgrades functional<br />
* The proposal must make it clear which recipes within the layer are being proposed to be built<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of a new MACHINE target ===<br />
<br />
* Layers to build the machine need to be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Layers need to be buildable on the project autobuilder<br />
* Needs to be Yocto Project membership sponsorship of the machine due to the project resource usage<br />
* Needs to be a commitment to testing the images for the platform for releases and upgrades<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
<br />
=== Process and policy for proposing addition of new recipe to the build ===<br />
<br />
* This process assumes the layer is already present but the recipe is not currently included in the test matrix<br />
* The recipe would need to have demonstrated the ability to pass on target installation and upgrade<br />
* Proposals would be made to the Yocto Project TSC covering the above topics<br />
* The software needs to have a good maintenance track record including reasonable CVE response<br />
* Note: The TSC is aiming to appoint a maintainer to take the lead on resolving binary distro testing issues and handling recipe addition requests.<br />
<br />
=== TSC Criteria for change evaluation ===<br />
<br />
* Does the project have resources (human and compute for build/test/QA/bugfixing) to support the change?<br />
* Is the change widely useful to a significant portion of the user base?<br />
* Does the change enhance the project's test matrix?<br />
* Does the change significantly improve developer productivity?<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Project status ==<br />
<br />
Here is the status of the various deliverables, according to the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ project specifications]:<br />
<br />
# Define the scope of a binary distro prototype (which recipes and machines to target)<br />Completed - See the top of this page: [[#Scope of a Yocto Binary Distribution Prototype]]<br />
# Add automated testing of upgrading an image from our previous release to the current version using a package feed.<br />Ongoing. I have a modified version of testimage.bbclass and an opkgfeed.py test that tests that an upgrade from a previously generated image succeeds with the feeds generated for the version being tested. Now need to explore the approach suggested by Richard, based directly on testimage.<br />
# Implement PR server functionality to handle “pass through” mode and hierarchy data.<br />First [https://lore.kernel.org/bitbake-devel/20240329143956.1602707-1-michael.opdenacker@bootlin.com/T/#t patch series] submitted for the "passthrough" functionality. What about the "hierarchical data" feature mentioned in the specifications?<br />
# Automated testing of ability to assemble images quickly from sstate/PRServ/Hashequiv data.<br />To be started soon.<br />
# Propose policies/requirements on how a binary reference distro for the project would behave. Need to include proposed policies for including new recipes and extending to cover new platforms/architectures.<br />Draft version available on [[#Policies_and_Processes]], thanks to Richard and the TSC. Can this deliverable now be considered as "ready"?<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== FAQ ==<br />
<br />
Q: Can my product point at your package feed?<br />
A: No. The aim of this work is demonstrate the tools, processes and policies needed to build a binary distribution using the project. There is no commitment or guarantee to maintain the feeds for any product use case or with any guarantees around security issues. Please do not point products at these package feeds.<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86265Binary Distro Prototype2024-03-11T14:10:33Z<p>Michael Opdenacker: /* Testing plans */ Keep track of other scenarios that we may want to test</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
Here are other tests that would be worth implementing:<br />
* Check that package upgrades don't cause configuration file changes to be lost. See [https://lore.kernel.org/openembedded-core/0e38566f-a1f9-4ebb-8492-2c50945eeeb4@gmail.com/T/#t this discussion].<br />
* Check that the latest package upgrades successfully apply to any previous release, at least on the same branch. For example, upgrading directly from release x.y.n-2 to x.y may not work without going through x.y.n-1 as an intermediate. This could happen if a package has a really broken post-install script in n-2, which damage is repaired in n-1. Should n repair it too in case n-1 is skipped?<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86264Releases2024-03-11T10:02:43Z<p>Michael Opdenacker: /* Release Activity */ Update for 3.1.32</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/dev/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
!Notes<br />
|-<br />
|Styhead <br/>(like 'try head')<br />
|5.1<br />
| October 2024<br />
|<br />
|Future<br />
|N/A<br />
|2.10<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|[[Recipe_Versions|Recipe versions]]<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3.3 (March 2024)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Steve Sakoman <steve@sakoman.com><br />
|- style="color: slategray;"<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.4 (December 2023)<br />
| EOL<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.16 (February 2024)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.32 (Mar. 2024)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86133Releases2023-12-18T10:59:57Z<p>Michael Opdenacker: /* Release Activity */ update link to latest graphical timeline</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/dev/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3.1 (December 2023)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Steve Sakoman <steve@sakoman.com><br />
|- style="color: slategray;"<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.4 (December 2023)<br />
| EOL<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.14 (November 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.29 (November 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86118Binary Distro Prototype2023-12-06T15:59:53Z<p>Michael Opdenacker: /* Achievements */ Add improvements to the test manual</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
=== Yocto Project Documentation improvements ===<br />
<br />
* [https://lore.kernel.org/yocto-docs/20231206155427.279612-1-michael.opdenacker@bootlin.com/T/#t Fixes and updates to the Test Environment Manual]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86106Binary Distro Prototype2023-12-02T06:24:46Z<p>Michael Opdenacker: /* Out of scope */ Add footnotes and references section</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].<br />
<br />
== Footnotes and references ==</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86105Binary Distro Prototype2023-12-02T06:23:30Z<p>Michael Opdenacker: /* Available reference binary artifacts and deliverables */ Add footnotes about source packages</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPMs)<ref>Only Source RPMs are supported by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. To obtain them, you need to set <code>INHERIT += "archiver"</code>, <code>PACKAGE_CLASSES = "package_rpm"</code> and <code>ARCHIVER_MODE[srpm] = "1"</code>. The generation of source <code>deb</code> or <code>ipk</code> packages is currently not supported.</ref>.<ref>The <code>-src</code> packages which recipes can produce are only meant for debugging together with <code>-dbg</code> packages. See [https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_DEBUG_SPLIT_STYLE PACKAGE_DEBUG_SPLIT_STYLE].</ref><br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86103Binary Distro Prototype2023-12-01T19:03:14Z<p>Michael Opdenacker: /* Available reference binary artifacts and deliverables */ Add we won't produce source package feeds</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image, as produced by the [https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-archiver archiver] class. Unlike standard GNU/Linux distributions, we won't ship source package feeds (such as SRPM or <code>deb-src</code>).<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86102Binary Distro Prototype2023-12-01T18:11:11Z<p>Michael Opdenacker: /* Defining policies and processes */ Add link to new section</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
See the [[#Policies and Processes | Policies and Processes]].<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86101Binary Distro Prototype2023-12-01T17:27:57Z<p>Michael Opdenacker: /* Achievements */ Adding a section for drafting policies and processes</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Policies and Processes ==<br />
<br />
=== Criteria for adding and testing a new CPU architecture or platform tuning ===<br />
<br />
* Only tunes in Openembedded-Core should be supported.<br />
<br />
=== Criteria for testing other layers ===<br />
<br />
* Layers must be [https://docs.yoctoproject.org/current/dev-manual/layers.html#making-sure-your-layer-is-compatible-with-yocto-project Yocto Project Compatible]<br />
* Recipes to consider and all their dependencies should be already tested by the Autobuilder.<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86100Binary Distro Prototype2023-12-01T17:12:42Z<p>Michael Opdenacker: /* Target tunes */ Use the default tunes for qemux86-64 and qemuarm64</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated with the default tunes of the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] and [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machines.<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86099Binary Distro Prototype2023-12-01T17:00:48Z<p>Michael Opdenacker: /* Target architectures and machines */ Refocus prototypes on the builds for qemux86-64 and qemuarm64</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "x86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemux86-64.conf qemux86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine.<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86098Binary Distro Prototype2023-12-01T15:05:15Z<p>Michael Opdenacker: /* Open questions */ Add issue with arch strings</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
* Issues with Yocto Project being pedantic in its use of arch strings such as "intel-x86-64" instead of "x86-64". This conflicts with typical use in the greater Linux and "binary" community, which may not recognize the "extended" arch strings. Examples: [https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23 libresolv] and [https://github.com/rpm5/libhif/blob/f9b798cadb6821f9cffd5c0331578b3f7c19d699/libdnf/dnf-context.c#L52 libdnf] (reported by Mark Asselstine).<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86092Binary Distro Prototype2023-11-29T10:32:27Z<p>Michael Opdenacker: Mention distribution installers (out of scope)</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).<br />
<br />
== Out of scope ==<br />
<br />
Features outside of the scope of this effort, but definitely worth keeping track of for future efforts, or for people already maintaining binary distributions.<br />
* Binary distribution installer: not absolutely necessary but users may expect one. For example the [https://www.yoedistro.org/ Yoe] distro offers one, and so does [https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ Raspberry Pi].</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86091Binary Distro Prototype2023-11-28T18:24:13Z<p>Michael Opdenacker: /* Scope of a Yocto Binary Distribution Prototype */ Add links for Angstrom and Yoe</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as [[wikipedia:Ångström_distribution|Ångström]] or [https://www.yoedistro.org/ Yoe].<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86090Binary Distro Prototype2023-11-28T18:12:21Z<p>Michael Opdenacker: Add link to original Engineering Request for Quotation</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions (see the [https://web.archive.org/web/20230620145823/https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Engineering Request for Quotation]). As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as Angstrom or Yoe.<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86089Binary Distro Prototype2023-11-28T18:08:10Z<p>Michael Opdenacker: Add "Fixed bugs" section</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions. As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as Angstrom or Yoe.<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
== Achievements ==<br />
<br />
=== Fixed bugs ===<br />
<br />
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15292 Bug 15292 - systemd-compat-units: error at package post-install time]<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86088Binary Distro Prototype2023-11-28T17:04:56Z<p>Michael Opdenacker: Add a section documenting the identified missing features</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions. As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as Angstrom or Yoe.<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
=== Open questions ===<br />
<br />
== Missing features ==<br />
<br />
Not implemented yet:<br />
* Ability to update the system SPDX description after installing extra packages or package updates. The current way SPDX is generated doesn't allow to generate <code>-spdx</code> packages, which would have made this possible ([https://lists.openembedded.org/g/openembedded-architecture/message/1855 discussion]).</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Binary_Distro_Prototype&diff=86087Binary Distro Prototype2023-11-28T16:53:43Z<p>Michael Opdenacker: Initial version</p>
<hr />
<div>== Scope of a Yocto Binary Distribution Prototype ==<br />
<br />
The Yocto Project has received funding for developing the processes and tooling for enabling binary distributions. As part of that, the project would need some form of prototype test binary distro to develop and test this. The main goal of this would be to develop the tools, and documentation needed to build a binary distribution and allow application and system developers to progress through a hierarchy of different uses of the resulting environment:<br />
<br />
* '''Beginner''' use case: begin by fetching a binary image, ready to boot on a target machine. Extend the system by installing extra applications through package feeds.<br />
* '''Intermediate''' use case: tweak and rebuild existing packages, compile new applications and modify images by using an eSDK and other binary artifacts.<br />
* '''Advanced''' use case: completely reorganize and optimize the system for a specific target, switching to building from source<br />
<br />
The first step in this effort is to define the scope of the prototype we will develop. We are looking for feedback and comments about issues we may not have considered.<br />
<br />
Bear in mind that a prototype has to be limited in scope. However, the developed tools, procedures and documentation will open a pathway for the Yocto Project and OpenEmbedded community to experiment with more architectures, features, recipes and images.<br />
<br />
Also bear in mind that the effort is not planning to adopt, replace or repeat any existing distributions such as Angstrom or Yoe.<br />
<br />
Notes from discussions:<br />
* Alex Kanavin suggests as "Intermediate" step to use the [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles] that he submitted. However, this is closer to the "Advanced" use case as this already uses BitBake and OE/Yocto ([https://lists.openembedded.org/g/openembedded-architecture/message/1850 discussion]).<br />
<br />
=== Target architectures and machines ===<br />
<br />
The first prototype would only target the below architectures:<br />
* "genericx86-64" architecture through the [https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/genericx86-64.conf genericx86-64] machine.<br />
* "arm64" architecture through the [https://git.yoctoproject.org/poky/tree/meta/conf/machine/qemuarm64.conf qemuarm64] machine (and later "genericarm64" when ready).<br />
<br />
Testing would happen through QEMU system emulation. The emulated architectures will be sufficient to test the outputs of this effort, but the developed tooling and documentation should allow the community to experiment with other target architectures and machines.<br />
<br />
=== Target tunes ===<br />
<br />
The binary images and other artifacts should be generated for the below tunes:<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc armv8a]<br />
* [https://git.yoctoproject.org/poky/tree/meta/conf/machine/include/x86/tune-core2.inc core2-64]<br />
<br />
See [https://docs.yoctoproject.org/ref-manual/variables.html#term-DEFAULTTUNE DEFAULTTUNE] for details.<br />
<br />
=== Distribution, Init Manager, C library ===<br />
<br />
Images and package feeds will be generated for the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution, using the systemd init manager.<br />
<br />
Choosing systemd makes the binary reference distribution as generic as possible, enabling the widest set of features, and being more familiar to more users. Of course, switching to other init managers and more restricted features will be possible by later compiling the system from source (advanced use case).<br />
<br />
This also implies the choice of the GNU C library (glibc). Selecting glibc also makes sense to enable the widest possible selection of packages, and some packages have limited or no support for the Musl C library. That's typically the case of systemd, which upstream only supports glibc.<br />
<br />
Last but not least, people who want to use the Musl C library probably do that to optimize the size of their system, which is a use case not well adapted to using ready-made binary images. <br />
Such an advanced use case will be addressed by re-compiling from source, after testing initial prototypes with the binary image based on glibc.<br />
<br />
=== Binary images ===<br />
<br />
The prototype will provide as a reference, for each targeted architecture:<br />
* The root filesystem binary image, generated by building the <code>core-image-full-cmdline</code> target.<br />
* An image containing on-target development tools (e.g compiler, debugger)<br />
* The corresponding SD card images to be booted through QEMU. Other boot methods will be possible, but will be outside of the scope of the reference distribution.<br />
<br />
=== Package feeds ===<br />
<br />
For each targeted architecture, several package feeds will be available to allow for bugfix or security updates or to extend the image with additional packages:<br />
* Architecture independent feed<br />
* Architecture dependent feed<br />
* Machine dependent feed<br />
See [https://docs.yoctoproject.org/dev-manual/packages.html#using-runtime-package-management Using Runtime Package Management] for details.<br />
<br />
The feeds for the first prototype will contain all the packages which are supported by the [https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf poky-altcfg] distribution as produced by the <code>bitbake world</code> command for the set of layers supplied by Poky.<br />
<br />
=== Available reference package formats ===<br />
<br />
To keep the first prototype simple, we will only release images and package feeds based on the "ipk" format supported by [[wikipedia:opkg|opkg]] package manager.<br />
<br />
Of course, the OpenEmbedded build system also supports the [[wikipedia:Deb_(file_format)|deb]] and [[wikipedia:RPM_Package_Manager|rpm]] package formats, so users will be able to generate their own images and feeds based on these other formats.<br />
<br />
Another reason for not providing "deb" and "rpm" packages is that we do not want inexperienced users to expect to be able to grab and use such packages produced for regular Linux distributions (Debian, Fedora, etc.). Being built with different C library versions and toolchains, the corresponding binaries are most likely to be broken anyway.<br />
<br />
=== Available reference binary artifacts and deliverables ===<br />
<br />
The first prototype will make the below binary artifacts publicly available:<br />
* Root filesystem images (as specified above)<br />
* Binary package feeds (as specified above)<br />
* [https://docs.yoctoproject.org/ref-manual/variables.html#term-PR PR] database, so that people can manage updates to packages, by importing the database in a local PR server.<br />
* Prebuilt object data ("Shared State cache) through a public server (see [https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS SSTATE_MIRRORS]), to reuse binary output already built by the Yocto Project autobuilders, to reduce the compile time of additional packages.<br />
* Hash Equivalence data through a public server (see [https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM BB_HASHSERVE_UPSTREAM]), to increase the reusability of prebuilt objects.<br />
<br />
Share State and Hash Equivalence data would be only useful to "Intermediate" and "Advanced" use cases, to rebuild parts or the whole system from source.<br />
<br />
Such artifacts will be served through a Content Delivery Network (CDN), to make sure that they can be downloaded fast enough from any location in the world, in a way that remains much faster than re-compiling such artifacts from sources.<br />
<br />
Those binaries should also be released along with:<br />
* Sources corresponding to the software used to build the image<br />
* SPDX output for the initial image<br />
* The build system and layer sources. A good fit would be Alex Kanavin's [https://patchwork.yoctoproject.org/project/oe-core/patch/20231107105844.712846-1-alex@linutronix.de/ build bundles].<br />
<br />
=== Defining policies and processes ===<br />
<br />
This reference binary distribution prototype will also drive the documentation of policies and process to address future work such as:<br />
* What criteria should a new CPU architecture or platform tuning meet to be added / tested?<br />
* What criteria should other layers meet to be tested, in addition to being already tested by the Autobuilder? Should these criteria only apply to specific recipes or to the entire layers containing them?<br />
<br />
=== Testing plans ===<br />
<br />
Here are the tests we plan to implement:<br />
* Producing and testing binary images through the autobuilder<br />
* Making nightly builds available to testers<br />
* Testing that package updates apply successfully:<br />
** Within the current stable branch (nanbield): from one release update to the next, and from the latest release update to the tip of the branch<br />
** Between release branches: from the latest update to our latest LTS (kirkstone), to the latest update to the current stable release (nanbield).<br />
* Testing that it's also possible to build and deploy packages from the meta-openembedded and meta-virtualization layers, as a way to assess the relevance of our policies and process for additional layers or recipes. This would also be a way to demonstrate the ability to build container images, which would be a great way to ship binary distributions.<br />
<br />
We will work with recipe maintainers to publish fixes for update issues that testing will find in recipes. Each issue will be reported in Bugzilla.<br />
<br />
Open questions<br />
How do we update the system SPDX description after installing package updates? Should we also generate <code>-spdx</code> packages, to allow us to update the toplevel SPDX (from a new script?).</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86071Releases2023-11-15T18:43:39Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.0.14 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3 (November 2023)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.14 (November 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.29 (November 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86070Releases2023-11-15T17:29:17Z<p>Michael Opdenacker: /* Release Activity */ Update for 3.1.29 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3 (November 2023)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.13 (October 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.29 (November 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=86066Releases2023-11-10T14:38:29Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.3 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| November 2023<br />
| 4.3 (November 2023)<br />
|Support for 7 months (until May 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.13 (October 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.28 (September 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85955Releases2023-10-06T07:48:30Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.0.13 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|5.0<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.13 (October 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.28 (September 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85949Releases2023-10-02T08:52:39Z<p>Michael Opdenacker: /* Release Activity */ Update for 3.1.28 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|4.4<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.12 (August 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.28 (September 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Bugs&diff=85925Documentation Bugs2023-09-14T11:51:09Z<p>Michael Opdenacker: New overview page for documentation bugs</p>
<hr />
<div>Based on [https://bugzilla.yoctoproject.org/buglist.cgi?email1=opdenacker&emailassigned_to1=1&emailtype1=substring&query_format=advanced&resolution=--- bugs assigned to Michael Opdenacker]</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85924Releases2023-09-12T19:10:35Z<p>Michael Opdenacker: /* Release Activity */ Improve link to releases diagram</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See also [https://docs.yoctoproject.org/_images/releases.svg a graphical release timeline].<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|4.4<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.12 (August 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.27 (August 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85923Releases2023-09-12T19:09:00Z<p>Michael Opdenacker: /* Release Activity */ Add link to releases diagram from documentation</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
See https://docs.yoctoproject.org/_images/releases.svg for graphical release timeline.<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|4.4<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.12 (August 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.27 (August 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 were originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85905Releases2023-09-04T10:14:06Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.2.3 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|4.4<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.3 (September 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.12 (August 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.27 (August 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 was originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85873Releases2023-08-11T09:35:09Z<p>Michael Opdenacker: /* Release Activity */ Update for 3.1.27 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Scarthgap<br />
|4.4<br />
| April 2024<br />
|<br />
|Future - Long Term Support (until April 2028)<br />
|N/A<br />
|2.8<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.2 (July 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.11 (July 2023)<br />
|Long Term Support (Apr. 2026¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.27 (August 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series and 4.0 was originally planned for two years but extended to four. Future LTS releases are planned for 4 years.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85806Releases2023-05-30T12:00:49Z<p>Michael Opdenacker: /* Release Activity */ Move Langdale to EOL</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.1 (May 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-style="color: slategray;"<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| EOL<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.10 (May 2023)<br />
|Long Term Support (minimum Apr. 2024¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.25 (May 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series was originally planned for two years but extended to four. No decision has been made about 4.0, it would be a decision by the project members who fund it. The project in unable to commit to funding the work multiple years in advance.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85805Releases2023-05-29T07:40:09Z<p>Michael Opdenacker: Update for 4.2.1 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2.1 (May 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| Support until May 2023<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.10 (May 2023)<br />
|Long Term Support (minimum Apr. 2024¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.25 (May 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series was originally planned for two years but extended to four. No decision has been made about 4.0, it would be a decision by the project members who fund it. The project in unable to commit to funding the work multiple years in advance.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85798Releases2023-05-24T08:16:47Z<p>Michael Opdenacker: /* Release Activity */ Update for 4.0.10 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2 (May 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| Support until May 2023<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.10 (May 2023)<br />
|Long Term Support (minimum Apr. 2024¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.25 (May 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series was originally planned for two years but extended to four. No decision has been made about 4.0, it would be a decision by the project members who fund it. The project in unable to commit to funding the work multiple years in advance.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenackerhttps://wiki.yoctoproject.org/wiki/index.php?title=Releases&diff=85783Releases2023-05-12T09:06:27Z<p>Michael Opdenacker: Update for 3.1.25 release</p>
<hr />
<div><!-- keywords: release names codenames versions version names numbers branches branchx --><br />
<br />
== Release Activity==<br />
<br />
Releases can be downloaded at https://www.yoctoproject.org/software-overview/downloads/<br />
<br />
{| class="wikitable" border="2"<br />
!Codename<br />
!Yocto Project Version<br />
!Release Date<br />
!Current Version<br />
!Support Level<br />
!Poky Version<br />
!BitBake branch<br />
! Maintainer<br />
|-<br />
|Nanbield <br/>(like 'man field')<br />
|4.3<br />
| October 2023<br />
|<br />
|Future - Support for 7 months (until April 2024)<br />
|N/A<br />
|2.6<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Mickledore<br />
|4.2<br />
| May 2023<br />
| 4.2 (May 2023)<br />
|Support for 7 months (until November 2023)<br />
|N/A<br />
|2.4<br />
|Richard Purdie <richard.purdie@linuxfoundation.org><br />
|-<br />
|Langdale<br />
|4.1<br />
| October 2022<br />
| 4.1.4 (May 2023)<br />
| Support until May 2023<br />
|N/A<br />
|2.2<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|Kirkstone <br/>(like 'kirk stun')<br />
|4.0<br />
|May 2022<br />
|4.0.9 (April 2023)<br />
|Long Term Support (minimum Apr. 2024¹)<br />
|N/A<br />
|2.0<br />
|Steve Sakoman <steve@sakoman.com><br />
|-<br />
|-style="color: slategray;"<br />
|Honister<br />
|3.4<br />
|October 2021<br />
|3.4.4 (May 2022)<br />
|EOL<br />
|N/A<br />
|1.52<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Hardknott<br />
|3.3<br />
|April 2021<br />
|3.3.6 (April 2022)<br />
|EOL<br />
|N/A<br />
|1.50<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|-style="color: slategray;"<br />
|Gatesgarth<br />
|3.2<br />
|Oct 2020<br />
|3.2.4 (May 2021)<br />
|EOL<br />
|N/A<br />
|1.48<br />
|Anuj Mittal <anuj.mittal@intel.com><br />
|-<br />
|Dunfell<br />
|3.1<br />
|April 2020<br />
|3.1.25 (May 2023)<br />
|Long Term Support (until Apr. 2024¹)<br />
|23.0<br />
|1.46<br />
|Steve Sakoman <steve@sakoman.com><br />
|-style="color: slategray;"<br />
|Zeus<br />
|3.0<br />
|October 2019<br />
|3.0.4 (August 2020)<br />
|EOL<br />
|22.0.3<br />
|1.44<br />
| Anuj/Armin<br />
|-style="color: slategray;"<br />
|Warrior<br />
|2.7<br />
|April 2019<br />
|2.7.4 (June 2020)<br />
|EOL<br />
|21.0<br />
|1.42<br />
|Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Thud<br />
|2.6<br />
|Nov 2018<br />
|2.6.4 (October 2019)<br />
|EOL<br />
|20.0<br />
|1.40<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Sumo<br />
|2.5<br />
|April 2018<br />
|2.5.3 (April 2019)<br />
|EOL<br />
|19.0<br />
|1.38<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Rocko<br />
|2.4<br />
|Oct 2017<br />
|2.4.4 (November 2018)<br />
|EOL<br />
|18.0<br />
|1.36<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Pyro<br />
|2.3<br />
|May 2017<br />
|2.3.4 (July 2018)<br />
|EOL<br />
|17.0<br />
|1.34<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Morty<br />
|2.2<br />
|Nov 2016<br />
|2.2.4 (July 2018)<br />
|EOL<br />
|16.0<br />
|1.32<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Krogoth<br />
|2.1<br />
|Apr 2016<br />
|2.1.3 (July 2017)<br />
|EOL<br />
|15.0<br />
|1.30<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Jethro<br />
|2.0<br />
|Nov 2015<br />
|2.0.3 (January 2016)<br />
|EOL<br />
|14.0<br />
|1.28<br />
|Robert Yang <liezhi.yang@windriver.com><br />
|-style="color: slategray;"<br />
|Fido<br />
|1.8<br />
|Apr 2015<br />
|1.8.2<br />
|EOL<br />
|13.0<br />
|1.26<br />
|Joshua Lock <joshua.g.lock@intel.com><br />
|-style="color: slategray;"<br />
|Dizzy<br />
|1.7<br />
|Oct 2014<br />
|1.7.3<br />
|EOL<br />
|12.0<br />
|1.24<br />
| Armin Kuster <akuster808@gmail.com><br />
|-style="color: slategray;"<br />
|Daisy<br />
|1.6<br />
|Apr 2014<br />
|1.6.3<br />
|EOL<br />
|11.0<br />
|1.22<br />
| Saul Wold <sgw@linux.intel.com><br />
|-style="color: slategray;"<br />
|Dora<br />
|1.5<br />
|Oct 2013<br />
|1.5.4<br />
|EOL<br />
|10.0<br />
|1.20<br />
| Robert Yang <liezhi.yang@windriver.com> <br />
|-style="color: slategray;"<br />
|Dylan<br />
|1.4<br />
|Apr 2013<br />
|1.4.3<br />
|EOL<br />
|9.0<br />
|1.18<br />
| Paul Eggleton <paul.eggleton@linux.intel.com> <br />
|-style="color: slategray;"<br />
|Danny<br />
|1.3<br />
|Oct 2012<br />
|1.3.2<br />
|EOL<br />
|8.0<br />
|1.16<br />
|Ross Burton <ross.burton@intel.com> <br />
|-style="color: slategray;"<br />
|Denzil<br />
|1.2<br />
|Apr 2012<br />
|1.2.2<br />
|EOL<br />
|7.0<br />
|1.15<br />
|-style="color: slategray;"<br />
|Edison<br />
|1.1<br />
|Oct 2011<br />
|1.1.2<br />
|EOL<br />
|6.0<br />
|1.13<br />
|-style="color: slategray;"<br />
|Bernard<br />
|1.0<br />
|Apr 2011<br />
|1.0.2<br />
|EOL<br />
|5.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Laverne<br />
|0.9<br />
|Oct 2010<br />
|<br />
|<br />
|4.0<br />
|1.11<br />
|-style="color: slategray;"<br />
|Green<br />
|N/A<br />
|11 June 2010<br />
|<br />
|<br />
|3.3<br />
|<br />
|-style="color: slategray;"<br />
|Purple<br />
|N/A<br />
|15 Dec 2009<br />
|<br />
|<br />
|3.2<br />
|<br />
|-style="color: slategray;"<br />
|Pinky<br />
|N/A<br />
|12 Nov 2009<br />
|<br />
|<br />
|3.1<br />
|<br />
|-style="color: slategray;"<br />
|Blinky<br />
|N/A<br />
|1 Aug 2007<br />
|<br />
|<br />
|3.0<br />
|<br />
|-style="color: slategray;"<br />
|Clyde<br />
|N/A<br />
|19 Jan 2007<br />
|<br />
|<br />
|2.0<br />
|<br />
|-style="color: slategray;"<br />
|Inky<br />
|N/A<br />
|10 Feb 2006<br />
|<br />
|<br />
|1.0<br />
|<br />
|}<br />
<br />
'''Note:''' see also [[Stable Release and LTS]], [[Linux Yocto]], [[Planning]] and [[Release Feature Table]] pages. EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.<br />
<br />
¹ The 3.1 series was originally planned for two years but extended to four. No decision has been made about 4.0, it would be a decision by the project members who fund it. The project in unable to commit to funding the work multiple years in advance.<br />
<br />
== Releases Links==<br />
{| class="wikitable" border="2"<br />
| align="center" style="background:#f0f0f0;"|'''Yocto Project Release'''<br />
| align="center" style="background:#f0f0f0;"|'''Code Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Poky version'''<br />
| align="center" style="background:#f0f0f0;"|'''Maintainer'''<br />
| align="center" style="background:#f0f0f0;"|'''Features'''<br />
| align="center" style="background:#f0f0f0;"|'''Schedule'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Plan'''<br />
| align="center" style="background:#f0f0f0;"|'''QA Test Report'''<br />
| align="center" style="background:#f0f0f0;"|'''Release notes'''<br />
<br />
|-valign="top"<br />
| Yocto Project 3.4<br />
| Honister<br />
| 26.0<br />
| Anuj Mittal<br />
| [[Yocto_3.4_Features]]<br />
| [[Yocto_3.4_Schedule]]<br />
| [[Yocto_Project_v3.4_Status]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan | Yocto_3.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.4_Release_Test_Plan#Execution_History | 3.4 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/229 3.4 release notes]<br />
|-<br />
| Yocto Project 3.3<br />
| Hardknott<br />
| 25.0<br />
| Anuj Mittal<br />
| [[Yocto_3.3_Features]]<br />
| [[Yocto_3.3_Schedule]]<br />
| [[Yocto_Project_v3.3_Status]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan | Yocto_3.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.3_Release_Test_Plan#Execution_History | 3.3 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto-announce/message/215 3.3 release notes]<br />
|-<br />
| Yocto Project 3.2<br />
| Gatesgarth<br />
| 24.0<br />
| Anuj Mittal<br />
| [[Yocto_3.2_Features]]<br />
| [[Yocto_3.2_Schedule]]<br />
| [[Yocto_Project_v3.2_Status]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan | Yocto_3.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.2_Release_Test_Plan#Execution_History | 3.2 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/51262 3.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 3.1<br />
| Dunfell<br />
| 23.0<br />
| Steve Sakoman<br />
| [[Yocto_3.1_Features]]<br />
| [[Yocto_3.1_Schedule]]<br />
| [[Yocto_Project_v3.1_Status]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan | Yocto_3.1_Overall_Test_Plan]]<br />
| [[Yocto_Project_3.1_Release_Test_Plan#Execution_History | 3.1 qa run history]]<br />
| [https://lists.yoctoproject.org/g/yocto/message/49201 3.1 release notes]<br />
|-<br />
<br />
|-valign="top"<br />
| Yocto Project 3.0<br />
| Zeus<br />
| 22.0<br />
| Armin Kuster/Anuj Mittal<br />
| [[Yocto_2.8_Features]]<br />
| [[Yocto_2.8_Schedule]]<br />
| [[Yocto_Project_v2.8_Status]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan | Yocto_2.8_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.8_Release_Test_Plan#Execution_History | 2.8 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-October/047111.html 3.0 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.7<br />
| Warrior<br />
| 21.0<br />
| Community<br />
| [[Yocto_2.7_Features]]<br />
| [[Yocto_2.7_Schedule]]<br />
| [[Yocto_Project_v2.7_Status]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan | Yocto_2.7_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.7_Release_Test_Plan#Execution_History | 2.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto/2019-May/045028.html 2.7 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.6<br />
| Thud<br />
| 20.0<br />
| Community<br />
| [[Yocto_2.6_Features]]<br />
| [[Yocto_2.6_Schedule]]<br />
| [[Yocto_Project_v2.6_Status]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan | Yocto_2.6_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.6_Release_Test_Plan#Execution_History | 2.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-November/000147.html 2.6 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.5<br />
| Sumo<br />
| 19.0<br />
| Community<br />
| [[Yocto_2.5_Features]]<br />
| [[Yocto_2.5_Schedule]]<br />
| [[Yocto_Project_v2.5_Status]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan | Yocto_2.5_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.5_Release_Test_Plan#Execution_History | 2.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html 2.5 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.4<br />
| Rocko<br />
| 18.0<br />
| Community<br />
| [[Yocto_2.4_Features]]<br />
| [[Yocto_2.4_Schedule]]<br />
| [[Yocto_Project_v2.4_Status]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan | Yocto_2.4_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.4_Release_Test_Plan#Execution_History | 2.4 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-October/000125.html 2.4 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.3<br />
| Pyro<br />
| 17.0<br />
| Community<br />
| [[Yocto_2.3_Features]]<br />
| [[Yocto_2.3_Schedule]]<br />
| [[Yocto_Project_v2.3_Status]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan | Yocto_2.3_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.3_Release_Test_Plan#Execution_History | 2.3 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html 2.3 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.2<br />
| Morty<br />
| 16.0<br />
| Community<br />
| [[Yocto_2.2_Features]]<br />
| [[Yocto_2.2_Schedule]]<br />
| [[Yocto_Project_v2.2_Status]]<br />
| [[Yocto_2.2_Overall_Test_Plan]]<br />
| [[Yocto_Project_2.2_Release_Test_Plan#Execution_History | 2.2 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-November/000101.html 2.2 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.1<br />
| Krogoth<br />
| 15.0<br />
| Community<br />
| [[Yocto_2.1_Features]]<br />
| [[Yocto_2.1_Schedule]]<br />
| [[Yocto_Project_v2.1_Status]]<br />
| [[Yocto_2.1_Overall_Test_Plan]]<br />
| [[2.1 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes]<br />
|-<br />
|-valign="top"<br />
| Yocto Project 2.0<br />
| Jethro<br />
| 14.0<br />
| Community<br />
| [[Yocto_1.9_Features]]<br />
| [[Yocto_1.9_Schedule]]<br />
| [[Yocto_Project_v1.9_Status]]<br />
| <br />
| [[1.9 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-November/000076.html 2.0 release notes]<br />
|-valign="top"<br />
| Yocto Project 1.8<br />
| Fido<br />
| 13.0<br />
| Community<br />
| [[Yocto_1.8_Features]]<br />
| [[Yocto_1.8_Schedule]]<br />
| [[Yocto_Project_v1.8_Status]]<br />
| [[Yocto_1.8_Overall_Test_Plan]]<br />
| [[1.8 qa run history]] <br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html 1.8 release notes]<br />
|-<br />
| Yocto Project 1.7<br />
| Dizzy<br />
| 12.0<br />
| Community<br />
| [[Yocto_1.7_Features]]<br />
| [[Yocto_1.7_Schedule]]<br />
| [[Yocto_Project_v1.7_Status]]<br />
| [[Yocto_1.7_Overall_Test_Plan]]<br />
| [[1.7 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-October/000053.html 1.7 release notes]<br />
|-<br />
| Yocto Project 1.6<br />
| Daisy<br />
| 11.0<br />
| Community<br />
| [[Yocto_1.6_Features]]<br />
| [[Yocto_1.6_Schedule]]<br />
| [[Yocto_Project_v1.6_Status]]<br />
| [[Yocto_1.6_Overall_Test_Plan]]<br />
| [[1.6 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2014-April/000045.html 1.6 release notes]<br />
|-<br />
| Yocto Project 1.5<br />
| Dora<br />
| 10.0<br />
| Community<br />
| [[Yocto_1.5_Features]]<br />
| [[Yocto_1.5_Schedule]]<br />
| [[Yocto_Project_v1.5_Status]]<br />
| [[Yocto_1.5_Overall_Test_Plan]]<br />
| [[1.5 qa run history]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-October/000037.html 1.5 release notes]<br />
|-<br />
| Yocto Project 1.4<br />
| Dylan<br />
| 9.0<br />
| Community<br />
| [[Yocto_1.4_Features]]<br />
| [[Yocto_1.4_Schedule]]<br />
| [[Yocto_Project_v1.4_Status]]<br />
| [[Yocto_1.4_Overall_Test_Plan]]<br />
| [[Yocto_1.4_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html 1.4 release notes]<br />
|-<br />
| Yocto Project 1.3<br />
| Danny<br />
| 8.0<br />
| Community<br />
| [[Yocto_1.3_Features]]<br />
| [[Yocto_1.3_Schedule]]<br />
| [[Yocto_Project_v1.3_Status]]<br />
| [[Yocto_1.3_Overall_Test_Plan]]<br />
| [[Yocto_1.3_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-October/000020.html 1.3 release notes]<br />
|-<br />
| Yocto Project 1.2<br />
| Denzil<br />
| 7.0<br />
| Community<br />
| [[Yocto_1.2_Features]]<br />
| [[Yocto_1.2_Schedule]]<br />
| [[Yocto_Project_v1.2_Status]]<br />
| [[Yocto_1.2_Overall_Test_Plan]]<br />
| [[Yocto_1.2_Milestone_Test_Report]]<br />
| [https://lists.yoctoproject.org/pipermail/yocto-announce/2012-April/000009.html 1.2 release notes]<br />
|-<br />
| Yocto Project 1.1<br />
| Edison<br />
| 6.0<br />
| Community<br />
| [[Yocto_1.1_Features]]<br />
| [[Yocto_1.1_Schedule]]<br />
| [[Yocto_Project_v1.1_Release_Criteria]]<br />
| [[Yocto_1.1_Overall_Test_Plan]]<br />
| [[Yocto_1.1_Milestone_Test_Report]]<br />
|<br />
|-<br />
| Yocto Project 1.0<br />
| Bernard<br />
| 5.0<br />
| Community<br />
| [[Yocto_Features]]<br />
| [[Yocto_1.0_Schedule]]<br />
| [[Yocto_Project_v1.0_Release_Criteria]]<br />
| [[Yocto_1.0_Overall_Test_Plan]]<br />
| <br />
|<br />
|}</div>Michael Opdenacker