mbox series

[0/7] Mark recipes whose point releases are fixes-only (2/3)

Message ID 20260804141135.3779287-1-daniel.turull@ericsson.com
Headers show
Series Mark recipes whose point releases are fixes-only (2/3) | expand

Message

Daniel Turull Aug. 4, 2026, 2:11 p.m. UTC 
From: Daniel Turull <daniel.turull@ericsson.com>

Second of three series opting recipes into UPSTREAM_STABLE_RELEASE_REGEX. The
first covered recipes whose upstream publishes a written stable-branch policy and
is in master-next. This one covers recipes with no such document, qualifying
instead on branch structure and changelog evidence; the third will cover smaller
components with weaker evidence.

Why
---

The Auto Upgrade Helper's --stable mode proposes upgrades only within a
stable point-release series, so it can be run against a stable branch
without pulling in feature releases. It needs to know, per recipe, which
upstream versions count as a point release, and that is upstream-specific:
for some projects the series is the major, for others major.minor, for
others a suffix that is not dot-separated at all.

upstream-stable-release-point.bbclass derives that regex from PV, and does
nothing until a recipe opts in. This is the enabling work, one recipe at a
time. It matters because point releases are where CVE and crash fixes land,
and counting only bumps since each branch forked, the stable branches have
taken few of them while master takes them routinely.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades

Method
------

Each recipe needed two things: a mechanism that can express its series, and
evidence that point releases in that series carry only fixes.

Screened out before any reading: version schemes that cannot express a point
release, development series (whose point releases are not fixes-only),
abandoned lines, and projects with no per-series branch or other
bugfix-only marker.

Evidence required for the rest:

 - a written upstream policy where one exists, cited by file and line at a
   pinned tag;
 - the changelog for two to three point releases, including at least one
   that is not the newest, with section headings enumerated before any prose
   is read;
 - release dates across series, which show whether the stable branches are
   actually released from: a version published when a strictly higher one
   already exists is a maintenance release by construction;
 - ABI signal where the project provides one, such as libtool version-info
   or a soname;
 - what the OE stable branches have actually done since forking.

A new command-line option, a new configuration option, or a changed
documented default in a point release is disqualifying. An additive API
symbol may be acceptable but is disclosed in the commit message rather than
glossed. Each commit message states what the point releases actually
contain, so the reasoning can be checked rather than taken on trust.

Scope
-----

None of the upstreams in this series publishes a standalone "this branch is
fixes-only" document, so qualification rests on the per-series branch itself
plus the actual changelog content. Each commit message enumerates what recent
point releases contain, along with the mechanism used and any caveat, so the
decision can be checked per recipe.

Where an upstream could not be shown to maintain its stable branches alongside
the current one, the recipe was dropped from this series rather than argued for
on weaker grounds. A per-series branch and a coordinated release history are not
sufficient on their own either: one candidate kept per-minor branches and shipped
its old series for a year alongside the new one, and was still rejected for
adding a configuration option in a point release.

These are collectively higher CVE-exposure recipes than the first series, so
coverage here has practical value even though the evidence is weaker than a
written policy.

Disclosure
----------

Produced with AI assistance, which did the screening, the changelog reading
and the drafting. I have reviewed each recipe myself: the qualification
decision, the evidence cited, and the resulting regex. Errors are mine.

The class exists only on master, hence the /dev/ documentation link and the
target branch.

Daniel Turull (7):
  libxml2: inherit upstream-stable-release-point
  python3: inherit upstream-stable-release-point
  openssl: inherit upstream-stable-release-point
  binutils: inherit upstream-stable-release-point
  libgcrypt: inherit upstream-stable-release-point
  sqlite3: inherit upstream-stable-release-point
  lttng-tools: inherit upstream-stable-release-point

 meta/recipes-connectivity/openssl/openssl_3.5.7.bb | 5 +++++
 meta/recipes-core/libxml/libxml2_2.15.3.bb         | 4 ++++
 meta/recipes-devtools/binutils/binutils.inc        | 5 +++++
 meta/recipes-devtools/python/python3_3.14.6.bb     | 4 ++++
 meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb    | 2 +-
 meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb | 2 +-
 meta/recipes-support/sqlite/sqlite3.inc            | 2 +-
 7 files changed, 21 insertions(+), 3 deletions(-)

Comments

David Partain Aug. 4, 2026, 2:40 p.m. UTC | #1 
On Tue, 2026-08-04 at 16:11 +0200, daniel.turull@ericsson.com wrote:
> From: Daniel Turull <daniel.turull@ericsson.com>
> 
> Second of three series opting recipes into UPSTREAM_STABLE_RELEASE_REGEX. The
> first covered recipes whose upstream publishes a written stable-branch policy
> and
> is in master-next. This one covers recipes with no such document, qualifying
> instead on branch structure and changelog evidence; the third will cover
> smaller
> components with weaker evidence.

These all look good to me.

David