Picking a Vendor BSP Branch: The Highest Number Is Not the Maintained One

A branch name is not a support statement. It is a string. Teams starting a board bring-up routinely open the vendor’s kernel repository, sort the branch list, and take the highest version — on the reasonable-sounding assumption that newer means better maintained. Two vendors in our tracker dataset currently demonstrate, with dates you can check yourself, that this assumption is wrong. This post shows how to tell a maintained vendor BSP branch from a staging one before you build a product on it.

Everything below was re-read from the vendor repositories and kernel.org on 14 July 2026. Branch heads move; the method is what you should keep, not the dates.

What changed: Qualcomm published qcom-6.19

The qualcomm-linux/kernel repository currently exposes these branches:

raghu@techveda.org:~$ git ls-remote --heads https://github.com/qualcomm-linux/kernel | awk '{print $2}'
refs/heads/main
refs/heads/qcom-6.18/tech/noup/debug/all
refs/heads/qcom-6.18.y
refs/heads/qcom-6.18.30
refs/heads/qcom-6.19
refs/heads/qcom-linux-next
refs/heads/qcom-next
refs/heads/qcom-next-staging
refs/heads/qcom-next-staging-topics

Sort that list and qcom-6.19 wins. Read it instead, and it loses. The head commit of qcom-6.19 is dated 11 March 2026. The head commit of qcom-6.18.y is dated 14 July 2026 — the day we checked. Four months of silence on one branch, active work on the other.

The commit subjects say the rest:

2026-03-11  FROMLIST: arm64: dts: qcom: monaco-evk: Add IFP Mezzanine
2026-03-11  Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Add Mezzanine"
2026-03-11  FROMLIST: arm64: dts: qcom: lemans-evk: Add IFP Mezzanine
2026-03-11  Revert "FROMLIST: arm64: dts: qcom: lemans-evk: Add Mezzanine"
2026-02-20  Prepare qcom-next based on tag 'Linux 6.19' of https://git.kernel.org/...
2026-02-19  Add qcom-next log files for 20260213

Three things are visible here. The branch was cut as qcom-next — an integration line — and merely named after the tag it was based on. Its patches carry the FROMLIST: prefix, meaning they were taken from a mailing-list posting that had not yet been merged upstream. And the work on it is a churn of applies and reverts, which is what an integration branch looks like, not what a product branch looks like.

The base kernel is the second tell

Look at what the branch is based on rather than what it is called. Linux 6.19 is not a long-term release. kernel.org’s releases.json on 14 July 2026 lists mainline 7.2-rc3 (12 July 2026), stable 7.1.3, and six longterm series: 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 and 5.10.260. 6.19 appears in none of those categories — it is a finished, unmaintained development release. 7.0 is now explicitly flagged end-of-life.

raghu@techveda.org:~$ curl -s https://www.kernel.org/releases.json | jq -r '.releases[] | [.moniker, .version, .released.isodate] | @tsv'
mainline    7.2-rc3     2026-07-12
stable      7.1.3       2026-07-04
stable      7.0.14      2026-06-27
longterm    6.18.38     2026-07-04
longterm    6.12.95     2026-07-04
longterm    6.6.144     2026-07-04
longterm    6.1.177     2026-07-04
longterm    5.15.211    2026-07-04
longterm    5.10.260    2026-07-04

So qcom-6.19 is a staging branch on top of a kernel that will never receive another stable fix, while qcom-6.18.y sits on an LTS series that is still taking patches — and its .y suffix is itself a signal that it tracks a stable series rather than a single tag. For QCS6490 and the other parts in that tree, qcom-6.18.y is the line to build on. We record it that way on the QCS6490 board page.

Rockchip: the same trap, older

This is not one vendor’s quirk. In rockchip-linux/kernel, the highest branch is develop-6.6. Its head commit is dated 1 September 2025. develop-6.1, the lower number, has a head commit dated 26 December 2025 — nearly four months more recent. The branch that looks newer has been sitting untouched for over ten months.

raghu@techveda.org:~$ git ls-remote --heads https://github.com/rockchip-linux/kernel | grep develop-6
<sha>  refs/heads/develop-6.1
<sha>  refs/heads/develop-6.6

A team that picks develop-6.6 for an RK3588 product because 6.6 > 6.1 inherits a tree with no security fixes flowing into it, and will discover that only when the first CVE lands. The date on the branch head was available the whole time.

How to check a vendor BSP branch in five minutes

Before you commit a product to a vendor branch, run these checks. They cost minutes and they are the difference between a maintained tree and an abandoned one.

1. Read the head commit date, not the branch name. git ls-remote gives you the SHA; fetch the branch and check the date. A branch that has not moved in six months is not being maintained, whatever it is called.
2. Read the last twenty commit subjects. Prefixes matter. FROMLIST: means not upstream yet. UPSTREAM: or BACKPORT: mean the patch is upstream and being carried deliberately. A branch dominated by FROMLIST: and reverts is an integration line.
3. Check the base kernel against kernel.org. If the branch is based on a version that is not a longterm series, its upstream fix supply has already stopped. Our kernel lifecycles tracker lists the current LTS series and their projected end dates.
4. Prefer branch names that track a series. A .y suffix (qcom-6.18.y) says the branch follows a stable series. A bare version says it was cut once from a tag.
5. Cross-check the Yocto layer. If your build uses meta-qcom, meta-ti or similar, the layer’s kernel recipe tells you which branch the vendor’s own build system consumes. We track which layers have actually cut a branch for the current LTS on the Yocto layers tracker.

What we cannot tell you

We cannot see Qualcomm’s or Rockchip’s internal roadmaps. It is entirely possible that qcom-6.19 is revived, or that a qcom-7.x line appears and becomes the product branch, or that Rockchip resumes develop-6.6. What we can say is what the public trees show on 14 July 2026: one branch is being fed and the other is not. That is a fact with a date on it, and it is the only kind of fact you can act on. Re-run the checks above at the point you make the decision — do not take our dates, or anyone else’s, as standing.

Key takeaways

• As of 14 July 2026, qcom-6.19 (head 11 March 2026, FROMLIST-only) is a staging branch; qcom-6.18.y (head 14 July 2026) is the maintained one.
• Linux 6.19 is not a longterm release. A vendor branch based on it has no upstream stable fixes flowing in, regardless of how current the number looks.
• Rockchip’s develop-6.6 has been static since 1 September 2025 while develop-6.1 moved as recently as 26 December 2025.
• Judge a vendor BSP branch by its head commit date, its commit prefixes, and whether its base kernel is an LTS — never by the version number in its name.

Branch selection, mainline-versus-vendor gap analysis, board bring-up and long-term kernel maintenance are work our engineers do for product companies. If you would rather it were done with you than for you, we also train your team on your own board and your own BSP, to whatever depth you need. See TECH VEDA engineering services.

Frequently asked questions

Why would a vendor publish a branch it does not maintain?
Because integration work has to live somewhere. qcom-6.19 was cut as qcom-next, an internal staging line for patches not yet merged upstream. Publishing it is useful; it just is not an invitation to ship from it.

What does the FROMLIST prefix mean?
It marks a patch taken from a mailing-list posting that has not been merged upstream yet. A branch whose recent commits are mostly FROMLIST: is carrying unaccepted work, which is normal for staging and unsuitable for a product line.

How do I know if my branch’s base kernel is still supported?
Compare it against the longterm list on kernel.org. On 14 July 2026 the maintained series are 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10. If your base version is not one of them, no further stable fixes are coming from upstream.

Is a stale vendor branch always a mistake to use?
Not always — if the product ships and never updates, it may not matter. But you are then taking on the entire security burden yourself, and you should decide that deliberately rather than discover it after the first CVE.

Further reading

• qualcomm-linux/kernel — branch list (qcom-6.18.y and qcom-6.19)
• qcom-6.19 commit history — head 11 March 2026, “Prepare qcom-next based on tag ‘Linux 6.19′”
• rockchip-linux/kernel — branch list (develop-6.1 and develop-6.6)
• kernel.org releases.json — the authoritative list of mainline, stable and longterm series
• kernel.org: Active kernel releases