Openembedded Core Discussions
 help / color / mirror / Atom feed
From: <daniel.turull@ericsson.com>
To: <openembedded-core@lists.openembedded.org>
Cc: <richard.purdie@linuxfoundation.org>, <paul@pbarker.dev>,
	<Randy.MacLeod@windriver.com>, <alex.kanavin@gmail.com>,
	Daniel Turull <daniel.turull@ericsson.com>
Subject: [PATCH 0/7] Mark recipes whose point releases are fixes-only (1/3)
Date: Fri, 31 Jul 2026 14:25:15 +0200	[thread overview]
Message-ID: <20260731122522.1647968-1-daniel.turull@ericsson.com> (raw)

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(-)



             reply	other threads:[~2026-07-31 12:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 12:25 daniel.turull [this message]
2026-07-31 12:25 ` [PATCH 1/7] util-linux: inherit upstream-stable-release-point daniel.turull
2026-07-31 12:25 ` [PATCH 2/7] systemd: " daniel.turull
2026-07-31 12:25 ` [PATCH 3/7] glib-2.0: " daniel.turull
2026-07-31 12:25 ` [PATCH 4/7] dbus: " daniel.turull
2026-07-31 12:25 ` [PATCH 5/7] xz: " daniel.turull
2026-07-31 12:25 ` [PATCH 6/7] git: " daniel.turull
2026-07-31 12:25 ` [PATCH 7/7] perl: " daniel.turull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260731122522.1647968-1-daniel.turull@ericsson.com \
    --to=daniel.turull@ericsson.com \
    --cc=Randy.MacLeod@windriver.com \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox