Development Status
Amlogic Vendor Kernel 4.9 (Amlogic-ng)
| CoreELEC | Release | Kodi | Family | SoC |
|---|---|---|---|---|
| 9.2.8 | EOL | Leia | GXBB | S905, S905H |
| GXM | S912 | |||
| 19.5 | EOL | Matrix | GXL | S805X, S805Y, S905X, S905D, S905L, S905M2, S905W |
| G12A | S905X2, S905Y2 | |||
| G12B | A311D, S922X | |||
| SM1 | S905D3, S905X3 | |||
| SC2 | S905X4 | |||
| 20.5 | FINAL | Nexus | GXL | S805X, S805Y, S905X, S905D, S905L, S905M2, S905W |
| G12A | S905X2, S905Y2 | |||
| G12B | A311D, S922X | |||
| SM1 | S905D3, S905X3 | |||
| SC2 | S905X4 (*) | |||
| 21.1 | STABLE | Omega | GXL | S805X, S805Y, S905X, S905D, S905L, S905M2, S905W |
| G12A | S905X2, S905Y2 (*) | |||
| G12B | A311D, S922X | |||
| SM1 | S905D3, S905X3 | |||
| SC2 | S905X4 (*) |
Amlogic Vendor Kernel 5.4 (Amlogic-ne)
| CoreELEC | Release | Kodi | Family | SoC |
|---|---|---|---|---|
| 20.5 | FINAL | Nexus | SC2 | S905X4 (*) |
| T7 | A311D2 | |||
| S4 | S905Y4, S905W2 | |||
| 21.1 | STABLE | Omega | SC2 | S905X4 (*) |
| T7 | A311D2 | |||
| S4 | S905Y4, S905W2 | |||
| S5 | S928X | |||
| 22.0 | ALPHA | Piers | G12A | S905X2, S905Y2 (*) |
| G12B | A311D, S922X | |||
| SM1 | S905D3, S905X3 | |||
| SC2 | S905X4 | |||
| T7 | A311D2 | |||
| S4 | S905Y4, S905W2 | |||
| S5 | S928X |
Amlogic Vendor Kernel 5.15 (Amlogic-no)
| CoreELEC | Release | Kodi | Family | SoC |
|---|---|---|---|---|
| 22.0 | ALPHA | Piers | G12A | S905X2, S905Y2 (*) |
| G12B | A311D, S922X | |||
| SM1 | S905D3, S905X3 | |||
| SC2 | S905X4 | |||
| T7 | A311D2 | |||
| S4 | S905Y4, S905W2 | |||
| S5 | S928X |
(*) Generation Amlogic-ne cut-off
(*) Generation Amlogic-no cut-off
Distribution
CoreELEC is distributed as Release to The Web (RTW) or Web Release, a means of software delivery that utilizes the Internet for distribution. No physical media are produced by Team CoreELEC with this type of release mechanism.
CoreELEC Development Cycle
The CoreELEC Development Cycle (CEDC) is defined by an agile methodology with clearly outlined processes for creating high-quality software.
Agile methodologies have been credited with making software projects more successful at meeting end-user, customer and business needs, and at producing software more quickly and responsively than traditional Waterfall methodologies.
Development Phases
The CEDC methodology focuses on the following phases of software development:
| Release | Legend | Notes |
|---|---|---|
| Alpha(α) | ■ | This is the first phase of software development and testing. In this phase, a team of developers writes and tests the software, while additional validations are performed by dedicated teams. Alpha software is not thoroughly tested, contains serious bugs, are generally unsuitable for the public and considered highly unstable. |
| Beta(β) | ■ | The next phase, β, begins when the software is feature complete but likely to still contain a significant number of bugs. In this phase, β-testers work closely together with the developers to fix the bugs. These releases are considered unsuitable for daily use. |
| RC | ■ | A release candidate (RC) is a β-version which has been thoroughly tested and has the potential to be a stable product. Unless significant bugs emerge, the product is safe for use with the public. |
| Stable | ■ | Also called Production Release, is the last release candidate (RC) which has passed all verifications and tests. The product is now a stable public release and considered safe to use. |
| Nightly | ■ | A nightly (or daily) build contains the latest version of CoreELEC, based on end-user feedback. Nightly builds include the latest security updates, new features, and bug fixes. They are available to the public. These builds are considered safe to use. |
Initial Phase
During the Initial Development Phase, called Internal Development, Team CoreELEC works closely together with hardware manufacturers, following the traditional Alpha → Beta → RC → Stable development cycle. Internal Development builds are unavailable to the public.
Distribution Phase
- After distribution of the Initial Public Release, Team CoreELEC uses end-user feedback to implement improvements and updates, which then are released as Nightly Builds. Nightly Builds add additional functionality, improved stability, software and security updates, and bug fixes to the existing installation.
- An accumulation of Nightly Builds leads to a Release Candidate.
- Several Release Candidates lead inadvertently to a Stable Release, after which the cycle is repeated until such time development ceases.
Updates
With automatic updates enabled:
- Release Candidates: automatic
- Stable releases: automatic
- Nightly builds: manual, changing to automatic once installed
This article covers the CoreELEC update cycle in greater detail.
End-of-Software-Development
At the end of a release’s Standard Support phase, the release enters its EOSD milestone.
Software versions that have reached their EOSD date are no longer supported with active software development.
While Team CoreELEC no longer provides software fixes (nightlies), the team will still investigate, troubleshoot and try to provide workarounds.
End-of-Life
For various reasons, products will eventually reach their natural End-of-Life (EOL).
Reasons include newer and better technologies being made available, marketplace changes, or source parts and technologies no longer being available. This phase is part of any technology product lifecycle.
In this phase, development ceases, and Team CoreELEC no longer provides technical support for the product.
Team CoreELEC tries to make the EOL process as seamless as possible for end-users and partners alike while providing transparency into what can be expected.
Service announcements are released prior to the products' End-of-Life date.
NOTE: EOL Software and Source Code remains available to the public.