Stable Release and LTS - Revision history

Yoann Congal: /* Normal process */

2026-03-16T16:44:27Z

Normal process

← Older revision		Revision as of 16:44, 16 March 2026
Line 140:		Line 140:
	## Push the changes to poky-contrib stable/{branch}-nut		## Push the changes to poky-contrib stable/{branch}-nut
	## git://git.yoctoproject.org/poky-contrib		## git://git.yoctoproject.org/poky-contrib
	# Test the changes on the autobuilder (see [[~~How to start a build on the Autobuilder~~]])		# Test the changes on the autobuilder (see [[The_Yocto_Autobuilder#Starting_Builds]])
	#* Make sure you check directly for the results of the build as these won't be reported to the yocto-builds mailing list.		#* Make sure you check directly for the results of the build as these won't be reported to the yocto-builds mailing list.
	## For any build failure, Defects should be opened		## For any build failure, Defects should be opened

Yoann Congal: /* Normal process */

2026-03-16T16:42:24Z

Normal process

← Older revision		Revision as of 16:42, 16 March 2026
Line 135:		Line 135:
	# yocto-docs changes should be in yocto-docs contrib/stable/{branch}-nut		# yocto-docs changes should be in yocto-docs contrib/stable/{branch}-nut
	## git://git.yoctoproject.org/yocto-docs		## git://git.yoctoproject.org/yocto-docs
	#~~Now~~ create your Poky distro for testing.		# For stable branches using a assembled poky repository (i.e. before whinlatter), now create your Poky distro for testing.
	## The Autobuilder requires changes to reside in poky, bitbake and openembedded-core		## The Autobuilder requires changes to reside in poky, bitbake and openembedded-core
	## Combine bitabke, core, meta-yocto and yocto-docs changes into one repo.		## Combine bitabke, core, meta-yocto and yocto-docs changes into one repo.

Yoann Congal: /* Normal process */

2026-03-16T16:41:14Z

Normal process

← Older revision		Revision as of 16:41, 16 March 2026
Line 131:		Line 131:
	# Openembedded-core changes should be be in the openembedded-core-contrib stable/{branch}-nut		# Openembedded-core changes should be be in the openembedded-core-contrib stable/{branch}-nut
	## https://git.openembedded.org/openembedded-core-contrib		## https://git.openembedded.org/openembedded-core-contrib
	# Meta-yocto changes should be in ~~poky-contrib~~ meta-yocto/stable/{branch}-nut		# Meta-yocto changes should be in meta-yocto-contrib stable/{branch}-nut
	## git://git.yoctoproject.org/~~poky~~-contrib		## git://git.yoctoproject.org/meta-yocto-contrib
	# yocto-docs changes should be in ~~poky-contrib~~ yocto-docs/stable/{branch}-nut		# yocto-docs changes should be in yocto-docs contrib/stable/{branch}-nut
	## git://git.yoctoproject.org/~~poky~~-~~contrib~~		## git://git.yoctoproject.org/yocto-docs
	#Now create your Poky distro for testing.		#Now create your Poky distro for testing.
	## The Autobuilder requires changes to reside in poky, bitbake and openembedded-core		## The Autobuilder requires changes to reside in poky, bitbake and openembedded-core

Yoann Congal: /* Requesting a fix in a stable branch */ replace a dead poky link with individual repos

2026-03-16T16:37:14Z

Requesting a fix in a stable branch: replace a dead poky link with individual repos

← Older revision		Revision as of 16:37, 16 March 2026
Line 112:		Line 112:
	With reference to the above policies, if you would like to request a backport of a commit in a newer release, you can either (a) do the backport yourself and send the patch marked with <tt>[branchname]</tt> to the appropriate mailing list; or alternatively (b) you can send a simple request giving commit hashes / URLs that you would like to be backported. In both cases it helps to CC the maintainer - refer to the [[Stable branch maintenance\|stable release table]].		With reference to the above policies, if you would like to request a backport of a commit in a newer release, you can either (a) do the backport yourself and send the patch marked with <tt>[branchname]</tt> to the appropriate mailing list; or alternatively (b) you can send a simple request giving commit hashes / URLs that you would like to be backported. In both cases it helps to CC the maintainer - refer to the [[Stable branch maintenance\|stable release table]].

	For information on which mailing list you should send these to see the [~~http~~://git.yoctoproject.org/~~cgit~~/~~cgit~~.~~cgi~~/~~poky~~/tree/README README file~~] in~~ the ~~Poky repository~~.		For information on which mailing list you should send these to see the README file in [https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md OE-Core], [https://git.openembedded.org/bitbake/tree/README bitbake], [https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md meta-yocto], [https://git.yoctoproject.org/yocto-docs/tree/documentation/README yocto-docs]. Each repository should contain a README file at the root.

	== '''Maintainer Procedures''' ==		== '''Maintainer Procedures''' ==

Rpurdie: /* LTS “Mixin” repositories */

2024-03-21T15:29:18Z

LTS “Mixin” repositories

← Older revision		Revision as of 15:29, 21 March 2024
Line 54:		Line 54:
	We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers (see https://docs.yoctoproject.org/dev//ref-manual/release-process.html#stable-release-process).		We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers (see https://docs.yoctoproject.org/dev//ref-manual/release-process.html#stable-release-process).

	The structure would be to create them in the repository meta-lts-mixins with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too.		The structure would be to create them in the repository meta-lts-mixins with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too. Access to the repository branches can be granted by the Yocto Project TSC upon application.

	The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.		The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.

Paul Barker: Update LTS maintenance period

2023-12-08T07:30:10Z

Update LTS maintenance period

← Older revision		Revision as of 07:30, 8 December 2023
Line 26:		Line 26:
	'''Stable/LTS differences:'''		'''Stable/LTS differences:'''
	* Stable releases are maintained for seven months		* Stable releases are maintained for seven months
	* LTS releases are maintained ~~initially~~ for ~~two~~ years		* LTS releases are maintained for four years (as of June 2023, [https://lists.yoctoproject.org/g/yocto/message/60459 announced here])
	* LTS releases are preannounced and known to be LTS in advance (usually every two years)		* LTS releases are preannounced and known to be LTS in advance (usually every two years)
	* LTS tested only on a subset of supported native build platforms (announced at time of LTS)		* LTS tested only on a subset of supported native build platforms (announced at time of LTS)

Yoann Congal: /* Yocto Project Stable Branch Maintenance and Long Term Support (LTS) */ Shortcut the "Current Maintainers list" to the Release page to avoid a redirection.

2023-05-07T23:03:03Z

Yocto Project Stable Branch Maintenance and Long Term Support (LTS): Shortcut the "Current Maintainers list" to the Release page to avoid a redirection.

← Older revision		Revision as of 23:03, 7 May 2023
Line 3:		Line 3:
	Background on how the project's LTS plans came about can be found [[LTS_Background \| here]]. The document below details the current project release lifecycle and LTS plans. The aim is to have a stable series maintenance policy which allows for different stages of maintenance including standard "stable" series, LTS series and community support.		Background on how the project's LTS plans came about can be found [[LTS_Background \| here]]. The document below details the current project release lifecycle and LTS plans. The aim is to have a stable series maintenance policy which allows for different stages of maintenance including standard "stable" series, LTS series and community support.

	'''[[~~Stable branch maintenance~~\|Current Maintainers list]]'''		'''[[Releases\|Current Maintainers list]]'''

	== Release Lifecycle ==		== Release Lifecycle ==

Michael Opdenacker: /* LTS “Mixin” repositories */ Simplify text a bit, referring to the YP manual

2023-03-20T14:51:54Z

LTS “Mixin” repositories: Simplify text a bit, referring to the YP manual

← Older revision		Revision as of 14:51, 20 March 2023
Line 52:		Line 52:

	== LTS “Mixin” repositories ==		== LTS “Mixin” repositories ==
	We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers. ~~These would be thin specific purpose layers which can be stacked with an LTS~~ release ~~to mix a specific feature into that build~~. ~~These are to be created on an as needed basis and maintained by the people who need them~~. The structure would be to create them in the repository meta-lts-mixins with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too.		We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers (see https://docs.yoctoproject.org/dev//ref-manual/release-process.html#stable-release-process).

			The structure would be to create them in the repository meta-lts-mixins with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too.

	The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.		The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.

Rpurdie: /* LTS “Mixin” repositories */

2021-07-20T16:48:23Z

LTS “Mixin” repositories

← Older revision		Revision as of 16:48, 20 July 2021
Line 52:		Line 52:

	== LTS “Mixin” repositories ==		== LTS “Mixin” repositories ==
	We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers. These would be thin specific purpose layers which can be stacked with an LTS release to mix a specific feature into that build. These are to be created on an as needed basis and maintained by the people who need them. The structure would be to create them in the repository ~~oecore~~-~~backport~~-~~mixin~~ with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too.		We realise that a given LTS may need other versions of some components within its lifetime as no “one size” fits everyone’s needs. Rather than adding potentially invasive changes to older releases (such as new gcc versions), the project proposes the use of “mixin” layers. These would be thin specific purpose layers which can be stacked with an LTS release to mix a specific feature into that build. These are to be created on an as needed basis and maintained by the people who need them. The structure would be to create them in the repository meta-lts-mixins with the branch naming scheme <releaseseries>/<mixin name>. We expect this may be used for gcc and possibly for rapidly changing languages like go/nodejs/rust. Policies on testing these layers will depend on how widespread their usage is and determined on a case by case basis. There may be other 'mixin' layers within the wider community too.

	The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.		The layers should have a single purpose and be Yocto Project Compatible (passing the test script) allowing them to be selected by users as needed. The maintainer should be listed in the README and note when the layer is no longer maintained.

Armin Kuster: /* Release Lifecycle */

2020-03-13T19:16:53Z

Release Lifecycle

← Older revision		Revision as of 19:16, 13 March 2020
Line 45:		Line 45:

	'''EOL (End of life):'''		'''EOL (End of life):'''
			* No community support maintainer after the six (6) week waiting period
	* When there is no longer any active community maintainer, branches become EOL		* When there is no longer any active community maintainer, branches become EOL
			** No new changes for 2 months
			* Artifacts will be removed for EOL older than????
			** process under development

	== LTS “Mixin” repositories ==		== LTS “Mixin” repositories ==