Toradex Embedded Linux Support Strategy
Introduction
This article presents information about the embedded Linux release types, software alerts and software versioning scheme adopted by Toradex. It is valid for both Toradex's TorizonCore and Toradex BSP Layers and Reference Images for Yocto Project.
For BSP 3.X and 2.X please see Toradex Software Versioning Convention.
TorizonCore
TorizonCore is a binary distribution meant to be used as-is in production environments. Though you can do a custom Yocto Project build of TorizonCore, you are discouraged to do so as long as you don't need it.
Toradex Reference Images for Yocto Project
The Toradex Reference Images for Yocto Project are not production-ready, even for BSP releases that provide a production-grade quality. It is expected that you do your own custom build and take appropriate measures to harden and secure it.
Upstream Strategy
Starting with BSP 6.0 and the latest releases, all our supported 32-bit i.MX-based SoMs (i.e. NXP i.MX6, i.MX6 ULL and i.MX7 based modules) come to life with the latest stable mainline/upstream Linux kernel (eg mainline kernel v6.0 for BSP 6.0).
The i.MX8, i.MX 8X, i.MX 8M Mini and i.MX 8M Plus based modules still inherit the downstream-based BSP even for version 6.x and later, which are based on Toradex 5.15-2.x kernel (starting from toradex_5.15-2.0.x-imx). However, the Verdin SoMs based on NXP SoCs (Verdin iMX8M Mini and Verdin iMX8M Plus), also have an experimental version of the mainline kernel available as an alternative to the downstream-based BSP that is still supported on these boards.
For more information, please check ou Blog: Upstream First - Toradex Mainline Kernel Support is a Reality.
Embedded Linux Release Types
Overview
Toradex provides frequent releases for Embedded Linux, including both TorizonCore and our BSP Layers for Yocto. However, the support status for each release type is dependent not only on its frequency (nightly, monthly and quarterly), but also on the targeted hardware support status. The following table provides a quick reference for each combination of hardware and software status, and what the release support status is for that match (only for Embedded Linux releases).
For more details on each release type, please read the rest of this article.
Nightly Embedded Linux Releases
Qualification: No testing, may not boot
Intended Use: Typically only used in development to focus on a feature or bug fix coming up in a monthly release.
Typical Content: The features, fixes, made that day.
Release Cycle: On most nights, before midnight
Version example: 4.3.0+devel-20200120+build.65
Version Name Identifier: devel with year, month and day
Toradex Easy Installer Feeds: CI Feed
Maintenance Duration: Not maintained as we release on most days.
Supported Hardware: Nightly builds are released for any hardware, regardless of the product state or availability.
Monthly Embedded Linux Releases
Qualification: Basic testing
Intended Use: These releases are ideal for the development phase of a product, proof of concept, prototype series.
Typical Content: New Features, bug fixes,...
Release Cycle: Typically every month
Version example: 4.3.0+devel-201909+build.65
Version Name Identifier: devel, with year and month
Toradex Easy Installer Feeds: CI Feed
Maintenance Duration: Not maintained, for patches use nightly builds
Supported Hardware: Monthly builds are released for any hardware, regardless of the product state or availability.
Quarterly Embedded Linux Releases
Qualification: Full testing
Intended Use: These are extensively tested releases intended to be used in production devices. There are frequent new features.
Typical Content: Feature Set of the previous Monthly Release plus bug and security fixes.
Release Cycle: At the end of every Quarter, 4 times a year
Version example: 4.3.0
Version Name Identifier: None
Toradex Easy Installer Feeds: Main Feed
Maintenance Duration: 3 Months after the release
Supported Hardware: Intended to be used on volume products. For any other product state, quarterly releases must be treated as monthly.
Long Term Supported (LTS) Embedded Linux Releases
Qualification: Full testing
Intended Use: These are extensive tested releases intended to be used in production devices. They are recommended if you are not able to follow the quarterly release and new features are not important.
Typical Content: Feature Set of last Quarterly release plus bug fixes. Typically build with LTS Yocto Project and Kernel Versions.
Release Cycle: Once a year
Version example: 4.3.2+build.410
Version Name Identifier: None
Toradex Easy Installer Feeds: Main Feed
Maintenance Duration: 3 Years after release (see Maintenance Releases for Long Term Embedded Linux Release (LTS) )
Supported Hardware: Intended to be used on volume products. For any other product state, LTS releases must be treated as monthly.
Maintenance Releases for Quarterly Release
Toradex will provide critical bug fixes and security patches.
For non-critical issues, it's typically recommended to move to the next quarterly release.
Maintenance Releases for Long Term Embedded Linux Release (LTS)
Toradex continuously maintains LTS releases by providing bug fixes and security patches:
- In case there are any hardware changes required e.g because of a component going end-of-life, Toradex fully supports and validates the new hardware version and does any necessary software backports to support them.
- Those updates are provided to customers as maintenance releases in the form of source code and binary images.
- Toradex provides updates for the software components. They consist of fixed versions of the U-Boot boot loader, Linux kernel and OpenEmbedded/Yocto Project components used on a specific Toradex LTS release.
- Those updates are provided as long as the respective version of the components still receive updates. They are typically maintained for 2 - 3 years and are subject to each component's release plan.
- Toradex uses Longterm/Stable Linux kernels for its own LTS releases whenever possible. It ensures that Toradex LTS releases receive kernel updates for an extended period of time.
Software Alerts
Critical software issues get announced via customer information notification emails to customers who purchased affected products.
In addition, we highly recommend that you sign up for updates on the detailed software release pages:
Software Versioning Scheme
Toradex uses the regular MAJOR.MINOR.PATCH versioning and follow largely Semantic Versioning.
MAJOR.MINOR.PATCH-[devel]-[DATE]+build.BUILD
Major
Represents breaking changes and will be done typically once a year. Such changes include new OpenEmbedded/Yocto Project versions, new Kernel Versions and other changes.
[2].0.0
Minor
Representing updates, or changes that should not break backward compatibility (e.g. stay with the same OpenEmbedded release which usually means core components such as GCC and glibc stay at the same major version). Incrementing minor will typically be done from one quarterly release to the next quarterly release.
2.[1].0
Patch
Patch releases are released on-demand, typically to fix a security issue or to fix a broken functionality for Quarterly and Long Term Support (LTS) Releases.
2.1.[1]
devel
Indicate a pre-release such as nighty or monthly releases.
devel
Date
Dates are added to pre-releases. The date can be used to distinguish pre-releases:
Monthly pre-releases: contain year and month.
202005
Nightly pre-releases: contain year, month and day.
20200514
If the time is also included it is a special development build.
Build number
To denote the build number we use the word build. The build number is added as build metadata, preceded by a plus (+) sign, and is incremented on each complete OpenEmbedded build. The build number should also be available in the root file system (should be available in /etc/issue or /etc/os-release through the means of DISTRO_VERSION).
+build.65
Software Artifacts Versioning
For software artifacts like the Linux kernel and U-Boot, we also add the Toradex Image version number to the localversion part of the software artifact version. For those artifacts, we only use the main version plus a denomination for pre-releases, -devel, plus a git hash instead of the build number. This avoids unnecessary rebuilds and makes it easy to trace back the source code those pieces are built from. Examples:
U-Boot: 2019.07-4.0.0-devel+git.03cac0835c
Linux: 5.3.10-4.0.0-devel+git.401bf3f29b1a
A high-level overview of the versions of U-Boot, the Linux kernel, and Yocto/OpenEmbedded for each Toradex Embedded Linux release, can be found in the Embedded Linux Release Matrix.
Full Examples - Embedded Linux Releases
| Release date | Release type | Version number | Comment |
|---|---|---|---|
| 05 May 2020 | Monthly | 4.0.0-devel-202005+build.201 | Monthly pre-release |
| 06 May 2020 | Nightly | 4.0.0-devel-20200506+build.315 | Nightly pre-elease |
| 04 June 2020 | Quarterly | 4.0.0+build.467 | Quaterly release |
| 04 July 2020 | Monthly | 4.1.0-devel-202007+build.567 | Monthly release |
| 21 December 2020 | Quarterly | 4.3.0+build.657 | LTS release |
Legacy Versioning
For information about Version for releases before 4.0.0 please have a look at Toradex Software Versioning Convention.