mbox series

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

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

Message

Daniel Turull July 31, 2026, 12:25 p.m. UTC 
From: Daniel Turull <daniel.turull@ericsson.com>

First of three series opting recipes into UPSTREAM_STABLE_RELEASE_REGEX.
This one covers the recipes whose upstream publishes a written stable-branch
policy, so qualification can be checked against a document rather than
inferred. Later series cover recipes qualifying on branch structure and
changelog evidence, and a smaller tail 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.

  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;
 - 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.

Disclaimer:

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.

Daniel

Daniel Turull (7):
  util-linux: inherit upstream-stable-release-point
  systemd: inherit upstream-stable-release-point
  glib-2.0: inherit upstream-stable-release-point
  dbus: inherit upstream-stable-release-point
  xz: inherit upstream-stable-release-point
  git: inherit upstream-stable-release-point
  perl: inherit upstream-stable-release-point

 meta/recipes-core/dbus/dbus_1.16.2.bb       | 6 ++++++
 meta/recipes-core/glib-2.0/glib.inc         | 4 +++-
 meta/recipes-core/systemd/systemd.inc       | 5 +++++
 meta/recipes-core/util-linux/util-linux.inc | 4 ++++
 meta/recipes-devtools/git/git_2.55.0.bb     | 4 ++++
 meta/recipes-devtools/perl/perl_5.44.0.bb   | 2 +-
 meta/recipes-extended/xz/xz_5.8.3.bb        | 4 ++++
 7 files changed, 27 insertions(+), 2 deletions(-)