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