|
| 1 | +# Releases & Support |
| 2 | + |
| 3 | +This page answers a question that comes up in every deployment: *how |
| 4 | +long will this version keep getting updates, and who makes them?* It |
| 5 | +describes how releases are numbered and branched, what goes into a |
| 6 | +patch release, and the levels of maintenance available for products |
| 7 | +that must stay on one version for years. |
| 8 | + |
| 9 | +## Version Numbers |
| 10 | + |
| 11 | +Releases are tagged `vYY.MM.z`: |
| 12 | + |
| 13 | +- `YY.MM` identifies the release *series*, e.g., `v26.08` |
| 14 | +- `z` is the patch level within that series, starting at `0` |
| 15 | + |
| 16 | +Release candidates leading up to a release are tagged `-rcN`, e.g., |
| 17 | +`v26.08.0-rc1`. They exist to flush out issues before the final tag |
| 18 | +and are not intended for production. |
| 19 | + |
| 20 | +A series starts on `main` and is tagged `vYY.MM.0`. Every patch release |
| 21 | +in that series is made on the branch `vYY.MM.x`, e.g., `v26.08.x`. The |
| 22 | +branch is never rebased and never gains features -- it only moves |
| 23 | +forward, one patch release at a time. |
| 24 | + |
| 25 | +## The Foundation: Kernel & Buildroot LTS |
| 26 | + |
| 27 | +Every release builds on a Linux kernel LTS series and a Buildroot LTS |
| 28 | +series, e.g., Linux 6.18.y and Buildroot 2025.02.x. Both upstream |
| 29 | +projects publish patch releases on their own schedule, carrying security |
| 30 | +and stability fixes. The team tracks them closely, and `main` moves to |
| 31 | +the latest patch level of both as soon as it is available. |
| 32 | + |
| 33 | +Within a release series, the LTS *line* never changes. A device on |
| 34 | +v26.08.z stays on the same kernel and Buildroot generation for the life |
| 35 | +of the series; what moves is the patch level, e.g., Linux 6.18.48 → |
| 36 | +6.18.49 → 6.18.51. Changing to a new kernel or Buildroot LTS brings new |
| 37 | +drivers, new behavior, and new regressions, so it only ever happens on |
| 38 | +`main`, in a new series. |
| 39 | + |
| 40 | + |
| 41 | + |
| 42 | +## Levels of Maintenance |
| 43 | + |
| 44 | +The first two levels are what the open source project itself provides, |
| 45 | +free of charge and without commitment. The last two are commercial |
| 46 | +services from [*Wires*][wires], the company sponsoring Infix |
| 47 | +development. They exist because some products cannot follow a monthly |
| 48 | +release train, and someone still has to do the work. |
| 49 | + |
| 50 | +| **Level** | **Provided by** | **Contains** | **When** | |
| 51 | +|-----------------------------|------------------------------|--------------------------------------------------------|------------------------------| |
| 52 | +| Latest release | The project, free | Features, fixes, latest kernel & Buildroot LTS patches | Roughly monthly | |
| 53 | +| Patch release on `vYY.MM.x` | The project, free | The fix that motivated it, plus LTS patch bumps | Only when one is scheduled | |
| 54 | +| Infix LTS | [*Wires*][wires], commercial | LTS patch bumps and backported fixes | Schedule set in the contract | |
| 55 | +| Custom agreement | [*Wires*][wires], commercial | Whatever the product needs | Per agreement | |
| 56 | + |
| 57 | +### Latest Release |
| 58 | + |
| 59 | +The supported version of the open source project is the latest release. |
| 60 | +New releases come roughly once a month and carry the same kernel and |
| 61 | +Buildroot LTS patch level as every other level below -- together with |
| 62 | +new features, refactoring, and everything else that landed on `main` |
| 63 | +since the previous series. |
| 64 | + |
| 65 | +For a lab, an evaluation, or any deployment that can follow the project, |
| 66 | +this is the recommended track: upgrade to the latest release, and the |
| 67 | +foundation stays current by itself. |
| 68 | + |
| 69 | +### Patch Release on a Release Branch |
| 70 | + |
| 71 | +Patch releases happen when there is a concrete reason, typically a fix |
| 72 | +someone needs on a version that has already shipped. There is no |
| 73 | +schedule, and no promise that a given series will ever see another patch |
| 74 | +release. Old branches remain on GitHub, but a branch with no patch |
| 75 | +release is not the same as a maintained branch. |
| 76 | + |
| 77 | +When a patch release *is* scheduled, the same recipe applies every time: |
| 78 | + |
| 79 | +1. The fix, or fixes, that motivated the release |
| 80 | +2. The latest kernel LTS patch level, ported from `main` |
| 81 | +3. The latest Buildroot LTS patch level, ported from `main` |
| 82 | + |
| 83 | +The last two are the important part. Someone who takes v26.08.2 for a |
| 84 | +single file permission fix also receives every kernel and Buildroot |
| 85 | +security fix published since v26.08.1, which is usually the larger part |
| 86 | +of their exposure. |
| 87 | + |
| 88 | +> [!IMPORTANT] |
| 89 | +> Ported means the *patch level* only: 6.18.49 → 6.18.51 and 2025.02.17 |
| 90 | +> → 2025.02.18. A patch release never moves to another LTS line, never |
| 91 | +> adds features, and never changes the YANG models, so a device can take |
| 92 | +> it without a configuration migration. |
| 93 | +
|
| 94 | +### Infix LTS (Commercial) |
| 95 | + |
| 96 | +For products that have to stay on one version for years, |
| 97 | +[*Wires*][wires] offers *Infix LTS*: maintenance of one release series, |
| 98 | +sold as a support contract. No series is designated LTS up front -- the |
| 99 | +series a product shipped on is the series that gets maintained. |
| 100 | + |
| 101 | +> [!IMPORTANT] |
| 102 | +> Infix LTS is a commercial service from [*Wires*][wires], not a |
| 103 | +> promise made by the open source project. A release series is |
| 104 | +> maintained this way only for as long as a contract covers it. |
| 105 | +
|
| 106 | +Compared to the level above, what changes is the trigger and the scope: |
| 107 | + |
| 108 | +- **Trigger:** updates are made on a schedule of their own, not in |
| 109 | + response to a request. Nobody has to notice a problem first, and the |
| 110 | + interval is agreed in the contract |
| 111 | +- **Scope:** besides the kernel and Buildroot LTS patch bumps, important |
| 112 | + fixes are backported from `main` -- security fixes first, then |
| 113 | + stability fixes relevant to the hardware and the feature set in use |
| 114 | +- **Work:** a dedicated team does the porting, testing, and release |
| 115 | + notes, and the result is regression tested on the hardware the |
| 116 | + contract covers |
| 117 | + |
| 118 | +### Custom Agreement (Commercial) |
| 119 | + |
| 120 | +Requirements differ, and some cannot be met by any of the above: a |
| 121 | +kernel held at a fixed version for a certification, a longer support |
| 122 | +period than the upstream LTS provides, extra hardware, or a private |
| 123 | +branch with customer-specific features. [*Wires*][wires] handles these |
| 124 | +case by case, see [Support][support] for how to get in touch. |
| 125 | + |
| 126 | +## Support Periods for Products |
| 127 | + |
| 128 | +Whoever ships the product is its manufacturer, and the support period |
| 129 | +promised to end users -- along with the vulnerability handling behind it |
| 130 | +-- belongs to them. This is what the EU Cyber Resilience Act (CRA) has |
| 131 | +made concrete for anyone selling into the European market. What this |
| 132 | +page defines is the operating system underneath: how long it keeps |
| 133 | +receiving fixes, and who produces them. |
| 134 | + |
| 135 | +Two things are worth settling before a product ships, not after: |
| 136 | + |
| 137 | +- **Which series it ships on**, and which level of maintenance covers |
| 138 | + that series. Building on the latest release and following it is a |
| 139 | + valid answer; so is an Infix LTS contract with [*Wires*][wires]. |
| 140 | + Shipping on an old series with no maintenance arrangement is the one |
| 141 | + combination that leaves nobody responsible for the next kernel CVE |
| 142 | +- **Whether the device can be updated in the field.** Updates that |
| 143 | + cannot be delivered are not updates. See [Upgrading the |
| 144 | + System](upgrade.md) for the update mechanism and rollback behavior |
| 145 | + |
| 146 | +## Questions |
| 147 | + |
| 148 | +For the open source project, use the [community resources][support]: |
| 149 | +GitHub issues and discussions, or Discord. For support contracts, Infix |
| 150 | +LTS, and custom agreements, contact [*Wires*][wires] -- by email at |
| 151 | +<infix@wires.se>. |
| 152 | + |
| 153 | +[support]: https://github.com/kernelkit/infix/blob/main/.github/SUPPORT.md |
| 154 | +[wires]: https://wires.se |
0 commit comments