RE: [bitbake-devel][RFC][PATCH 1/3] lib/bb/fetch2/git.py: add optional major_version parameter to latest_versionstring

Hi Alex,

Thanks for your suggestion. I agree with this solution. It will give us better meta data maintenance in the long run.
I'll get to it after 5/1 holiday.

Regards,
Qi

-----Original Message-----
From: Alexander Kanavin <[email protected]> 
Sent: Wednesday, April 29, 2026 7:15 PM
To: Chen, Qi <[email protected]>
Cc: [email protected]; [email protected]; MacLeod, Randy <[email protected]>
Subject: Re: [bitbake-devel][RFC][PATCH 1/3] lib/bb/fetch2/git.py: add optional major_version parameter to latest_versionstring

On Wed, 29 Apr 2026 at 05:24, <[email protected]> wrote:
> +    def latest_versionstring(self, ud, d, major_version=None):

...

> +            if major_version:
> +                if not pver.startswith(major_version+'.'):
> +                    continue

This handles one way of versioning bugfix releases (x.y.z -> x.y.z+1), but upstreams might invent all kinds of different ways. E.g. systemd is using x -> x.1 -> x.2 -> ..., or openssh is using x.y->x.yp1.

Let's make it more general. I'd suggest passing in an optional filter_regex argument that would be matched with a 'candidate'
version. Then the most common use case (point releases) could be supported like this:

upstream-stable-releases-point.bbclass:
UPSTREAM_MAJMIN_VERSION_REGEX = ... (set from ${PV}, e.g. 3.4.5 becomes 3\.4) UPSTREAM_STABLE_RELEASES_REGEX = "${MAJMIN_VERSION}\.\d+" (this in turn becomes 3\.4\.\d+)

systemd and openssh on the other hand could set UPSTREAM_STABLE_RELEASES_REGEX directly according to their custom versioning schemas.

Then recipes which are known to do release maintenance (in a way that's compatible with Yocto stable policy) via point releases could inherit that class or set regex directly. And recipeutils in oe-core would pick up the regex from UPSTREAM_STABLE_RELEASES_REGEX and pass it in to the fetcher's latest version function.

Alex