Stable branch maintenance

The Yocto Project maintains stable branches of Poky (OE-Core and BitBake). Typically, alongside the latest release the previous two releases are also maintained.

Stable branch maintainers

Major version	Current Version	Branch name	BitBake version	Maintainer
3.2	Dreaming	Gatesgarth	1.48	Richard Purdie <richard.purdie@linuxfoundation.org>
3.1	Dev	Dunfell	1.46	Richard Purdie <richard.purdie@linuxfoundation.org>
3.0	3.0.0	Zeus	1.44	Anju/Armin
2.7	2.7.2	Warrior	1.42	Armin Kuster <akuster808@gmail.com>
2.6	2.6.4	Thud	1.40	Armin Kuster <akuster808@gmail.com>
2.5	2.5.3	sumo	1.38	Armin Kuster <akuster808@gmail.com>
2.4	2.4.4	rocko	1.36	Armin Kuster <akuster808@gmail.com>
2.3	2.3.4	pyro	1.34	Armin Kuster <akuster808@gmail.com>
2.2	2.2.4	morty	1.32	Armin Kuster <akuster808@gmail.com>
2.1	2.1.3	krogoth	1.30	Armin Kuster <akuster808@gmail.com>
2.0	2.0.3	jethro	1.28	Robert Yang <liezhi.yang@windriver.com>
1.8	1.8.2	fido	1.26	Joshua Lock <joshua.g.lock@intel.com>
1.7	1.7.3	dizzy	1.24	Armin Kuster <akuster808@gmail.com>
1.6	1.6.3	daisy	1.22	Saul Wold <sgw@linux.intel.com>
1.5	1.5.4	dora	1.20	Robert Yang <liezhi.yang@windriver.com>
1.4	1.4.3*	dylan	1.18	Paul Eggleton <paul.eggleton@linux.intel.com>
1.3	1.3.2	danny	1.16	Ross Burton <ross.burton@intel.com>

(Versions in grey above are no longer actively maintained, but well-tested patches may still be accepted for them.)

Maintainer Procedures

Merge cycle

When there are enough changes (or a few critical ones), the stable branch maintainer should follow this procedure:

1. Look out for patches on the mailing list marked with the stable branch name in the subject
2. Look through recently merged patches in master that are suitable for backporting
3. Collect patches together on a branch
   • If a submitted patch is a backport from master, rather than taking the patch as submitted, it is preferable to backport the patch from master so that the original commit message is preserved.
   • If you do the backporting from poky you will get the original commit ID in the commit message which is useful for reference.
   • It is beneficial to change the original commit ID line to say "OE-Core master rev" instead of "OE-Core rev" to distinguish it from the OE-Core branch revision that will be added when the commit is merged
4. Run a local build or two to pick up any obvious problems
5. Test the branch on the autobuilder (see How to start a build on the Autobuilder)
   • Make sure you check directly for the results of the build as these won't be reported to the yocto-builds mailing list.
6. Split out any bitbake changes and send them to the bitbake-devel mailing list (marking them with the appropriate stable version in the subject line e.g. [1.20])
7. Split out OE-Core changes and create an openembedded-core-contrib branch containing them; send the cover letter only (marking it as such in the subject) to the openembedded-core mailing list.
8. Split out any meta-yocto changes and create a poky-contrib branch containing them; send the cover letter only (marking it as such in the subject) to the poky mailing list.
9. When the patches are merged, mark any bugs specific to the stable branch as resolved as appropriate.

There will very likely be a number of these cycles during the lifetime of the stable branch.

Point release

Normally point releases are scheduled in advance as appropriate - contact Stephen Jolley <sjolley.yp.pm@gmail.com> and CC: Ricard Purdie <richard.purdie@linuxfoundation.org> about scheduling point releases.

1. Send a patch to update the stable version in meta-yocto/conf/distro/poky.conf for the release
2. Once that is merged, ask Richard to run the release candidate build
   • The stable branch maintainer should monitor the build and follow up on any failures
3. When the release candidate build completes successfully, Branch Maintainer should notify the QA team to start the release QA process.
4. Gather together changes in the form needed for a release notes and send them Yocto Project TSC to so she can incorporate them in final release notes and to Stephen Jolley <sjolley.yp.pm@gmail.com> so he can have them in preparation for the release meeting.

Other

• It is useful to provide status updates on the Yocto Project technical call, particularly coming up to a stable release. If you're not able to be on the call, send the status update information to Stephen Jolley <stephen.k.jolley@intel.com> and he will present it.

Kernel LTS

Kernel cadence

Yocto LTS

Yocto LTS