[V5,1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

From: Chen Qi <Qi.Chen@windriver.com>

We want the ability to do stable version upgrades for recipes.
To this end, add an optional stable_upgrade parameter to the
get_recipe_upgrade_status function, which defaults to False and
when enabled will try to get the latest stable version of the recipe.

The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets
it, it will be used as the filter_regex. If it's not set explicitly,
it means that there's no stable updates or the recipe hasn't been
checked yet.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

Thanks, I think this is good and ready. I'll pick the auh patch when
bitbake and core patches merge.

We can add more recipes over time (e.g. openssl, webkit, glib, ...),
they don't have to be in the initial patchset. Probably a review of
scarthgap/whinlatter/walnascar/styhead commits can help identify more
recipes with stable maintenance releases as well.

Daniel's changelog extraction patches will also help a lot, take a look at them.

Alex


On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the
> get_recipe_upgrade_status function, which defaults to False and
> when enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets
> it, it will be used as the filter_regex. If it's not set explicitly,
> it means that there's no stable updates or the recipe hasn't been
> checked yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> index c6604f536d..7c1df518a8 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
>
>      return (pv, pfx, sfx)
>
> -def get_recipe_upstream_version(rd):
> +def get_recipe_upstream_version(rd, stable_upgrade):
>      """
>          Get upstream version of recipe using bb.fetch2 methods with support for
>          http, https, ftp and git.
> @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
>              except bb.fetch2.FetchError as e:
>                  bb.warn("Unable to obtain latest revision: {}".format(e))
>          else:
> -            pupver = ud.method.latest_versionstring(ud, rd)
> +            if stable_upgrade:
> +                stable_release_regex = rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> +                if stable_release_regex:
> +                    pupver = ud.method.latest_versionstring(ud, rd, filter_regex=stable_release_regex)
> +                else:
> +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX" means there's no stable upgrade
> +                    pupver = (ru['current_version'], None)
> +            else:
> +                pupver = ud.method.latest_versionstring(ud, rd)
>              (upversion, revision) = pupver
>
>          if upversion:
> @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
>
>      return ru
>
> -def _get_recipe_upgrade_status(data):
> -    uv = get_recipe_upstream_version(data)
> +def _get_recipe_upgrade_status(data, stable_upgrade):
> +    uv = get_recipe_upstream_version(data, stable_upgrade)
>
>      pn = data.getVar('PN')
>      cur_ver = uv['current_version']
> @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
>
>      return {'pn':pn, 'status':status, 'cur_ver':cur_ver, 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision, 'no_upgrade_reason':no_upgrade_reason}
>
> -def get_recipe_upgrade_status(recipes=None):
> +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
>      pkgs_list = []
>      data_copy_list = []
> +    stable_copy_list = []
>      copy_vars = ('SRC_URI',
>                   'PV',
>                   'DL_DIR',
> @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
>                   'UPSTREAM_CHECK_REGEX',
>                   'UPSTREAM_CHECK_URI',
>                   'UPSTREAM_VERSION_UNKNOWN',
> +                 'UPSTREAM_STABLE_RELEASE_REGEX',
>                   'RECIPE_MAINTAINER',
>                   'RECIPE_NO_UPDATE_REASON',
>                   'RECIPE_UPSTREAM_VERSION',
> @@ -1180,12 +1190,13 @@ def get_recipe_upgrade_status(recipes=None):
>                      data_copy.setVar(k, data.getVar(k))
>
>              data_copy_list.append(data_copy)
> +            stable_copy_list.append(stable_upgrade)
>
>              recipeincludes[data.getVar('FILE')] = {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')}
>
>      from concurrent.futures import ProcessPoolExecutor
>      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> +        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list, stable_copy_list)
>
>      return _group_recipes(pkgs_list, _get_common_include_recipes(recipeincludes))
>
> --
> 2.34.1
>

Hi,

I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.

Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.

Best regards,
Daniel

> -----Original Message-----
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Wednesday, 13 May 2026 11:36
> To: Qi.Chen@windriver.com
> Cc: openembedded-core@lists.openembedded.org;
> randy.macleod@windriver.com; Daniel Turull <daniel.turull@ericsson.com>
> Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade
> parameter to get_recipe_upgrade_status
> 
> Thanks, I think this is good and ready. I'll pick the auh patch when bitbake and
> core patches merge.
> 
> We can add more recipes over time (e.g. openssl, webkit, glib, ...), they don't have
> to be in the initial patchset. Probably a review of
> scarthgap/whinlatter/walnascar/styhead commits can help identify more recipes
> with stable maintenance releases as well.
> 
> Daniel's changelog extraction patches will also help a lot, take a look at them.
> 
> Alex
> 
> 
> On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
> >
> > From: Chen Qi <Qi.Chen@windriver.com>
> >
> > We want the ability to do stable version upgrades for recipes.
> > To this end, add an optional stable_upgrade parameter to the
> > get_recipe_upgrade_status function, which defaults to False and when
> > enabled will try to get the latest stable version of the recipe.
> >
> > The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets it,
> > it will be used as the filter_regex. If it's not set explicitly, it
> > means that there's no stable updates or the recipe hasn't been checked
> > yet.
> >
> > Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> > ---
> >  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
> >  1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> > index c6604f536d..7c1df518a8 100644
> > --- a/meta/lib/oe/recipeutils.py
> > +++ b/meta/lib/oe/recipeutils.py
> > @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
> >
> >      return (pv, pfx, sfx)
> >
> > -def get_recipe_upstream_version(rd):
> > +def get_recipe_upstream_version(rd, stable_upgrade):
> >      """
> >          Get upstream version of recipe using bb.fetch2 methods with support for
> >          http, https, ftp and git.
> > @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
> >              except bb.fetch2.FetchError as e:
> >                  bb.warn("Unable to obtain latest revision: {}".format(e))
> >          else:
> > -            pupver = ud.method.latest_versionstring(ud, rd)
> > +            if stable_upgrade:
> > +                stable_release_regex =
> rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> > +                if stable_release_regex:
> > +                    pupver = ud.method.latest_versionstring(ud, rd,
> filter_regex=stable_release_regex)
> > +                else:
> > +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX"
> means there's no stable upgrade
> > +                    pupver = (ru['current_version'], None)
> > +            else:
> > +                pupver = ud.method.latest_versionstring(ud, rd)
> >              (upversion, revision) = pupver
> >
> >          if upversion:
> > @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
> >
> >      return ru
> >
> > -def _get_recipe_upgrade_status(data):
> > -    uv = get_recipe_upstream_version(data)
> > +def _get_recipe_upgrade_status(data, stable_upgrade):
> > +    uv = get_recipe_upstream_version(data, stable_upgrade)
> >
> >      pn = data.getVar('PN')
> >      cur_ver = uv['current_version']
> > @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
> >
> >      return {'pn':pn, 'status':status, 'cur_ver':cur_ver,
> > 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision,
> > 'no_upgrade_reason':no_upgrade_reason}
> >
> > -def get_recipe_upgrade_status(recipes=None):
> > +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
> >      pkgs_list = []
> >      data_copy_list = []
> > +    stable_copy_list = []
> >      copy_vars = ('SRC_URI',
> >                   'PV',
> >                   'DL_DIR',
> > @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
> >                   'UPSTREAM_CHECK_REGEX',
> >                   'UPSTREAM_CHECK_URI',
> >                   'UPSTREAM_VERSION_UNKNOWN',
> > +                 'UPSTREAM_STABLE_RELEASE_REGEX',
> >                   'RECIPE_MAINTAINER',
> >                   'RECIPE_NO_UPDATE_REASON',
> >                   'RECIPE_UPSTREAM_VERSION', @@ -1180,12 +1190,13 @@
> > def get_recipe_upgrade_status(recipes=None):
> >                      data_copy.setVar(k, data.getVar(k))
> >
> >              data_copy_list.append(data_copy)
> > +            stable_copy_list.append(stable_upgrade)
> >
> >              recipeincludes[data.getVar('FILE')] =
> > {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')
> > }
> >
> >      from concurrent.futures import ProcessPoolExecutor
> >      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> > -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> > +        pkgs_list = executor.map(_get_recipe_upgrade_status,
> > + data_copy_list, stable_copy_list)
> >
> >      return _group_recipes(pkgs_list,
> > _get_common_include_recipes(recipeincludes))
> >
> > --
> > 2.34.1
> >

On Wed, 13 May 2026 at 11:44, Daniel Turull <daniel.turull@ericsson.com> wrote:
> I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.
>
> Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.
>

Just in case, I support the backport. The changes to bitbake/core are
not invasive, and they're in relatively 'safe' parts of the code that
aren't used in core workflows (e.g. actual builds aren't affected,
only the version checks and even there it's backwards compatible).

Alex

Hi Alex,

Thanks for your review. After these patches are merged, I think I can coordinate some of my colleagues to help with adding more recipes. In this way, the meta data for oe-core and meta-openembedded will be ready in one or two months.
Reviewing previous commits of released branches is really a good idea!
I think we'll also be checking repos, branches (as you suggested), changelogs and even upstreams directly to ensure the correctness.

Regards,
Qi

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@gmail.com> 
Sent: Wednesday, May 13, 2026 5:36 PM
To: Chen, Qi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org; MacLeod, Randy <Randy.MacLeod@windriver.com>; Daniel Turull <daniel.turull@ericsson.com>
Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

Thanks, I think this is good and ready. I'll pick the auh patch when bitbake and core patches merge.

We can add more recipes over time (e.g. openssl, webkit, glib, ...), they don't have to be in the initial patchset. Probably a review of scarthgap/whinlatter/walnascar/styhead commits can help identify more recipes with stable maintenance releases as well.

Daniel's changelog extraction patches will also help a lot, take a look at them.

Alex


On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the 
> get_recipe_upgrade_status function, which defaults to False and when 
> enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets it, 
> it will be used as the filter_regex. If it's not set explicitly, it 
> means that there's no stable updates or the recipe hasn't been checked 
> yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py 
> index c6604f536d..7c1df518a8 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
>
>      return (pv, pfx, sfx)
>
> -def get_recipe_upstream_version(rd):
> +def get_recipe_upstream_version(rd, stable_upgrade):
>      """
>          Get upstream version of recipe using bb.fetch2 methods with support for
>          http, https, ftp and git.
> @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
>              except bb.fetch2.FetchError as e:
>                  bb.warn("Unable to obtain latest revision: {}".format(e))
>          else:
> -            pupver = ud.method.latest_versionstring(ud, rd)
> +            if stable_upgrade:
> +                stable_release_regex = rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> +                if stable_release_regex:
> +                    pupver = ud.method.latest_versionstring(ud, rd, filter_regex=stable_release_regex)
> +                else:
> +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX" means there's no stable upgrade
> +                    pupver = (ru['current_version'], None)
> +            else:
> +                pupver = ud.method.latest_versionstring(ud, rd)
>              (upversion, revision) = pupver
>
>          if upversion:
> @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
>
>      return ru
>
> -def _get_recipe_upgrade_status(data):
> -    uv = get_recipe_upstream_version(data)
> +def _get_recipe_upgrade_status(data, stable_upgrade):
> +    uv = get_recipe_upstream_version(data, stable_upgrade)
>
>      pn = data.getVar('PN')
>      cur_ver = uv['current_version']
> @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
>
>      return {'pn':pn, 'status':status, 'cur_ver':cur_ver, 
> 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision, 
> 'no_upgrade_reason':no_upgrade_reason}
>
> -def get_recipe_upgrade_status(recipes=None):
> +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
>      pkgs_list = []
>      data_copy_list = []
> +    stable_copy_list = []
>      copy_vars = ('SRC_URI',
>                   'PV',
>                   'DL_DIR',
> @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
>                   'UPSTREAM_CHECK_REGEX',
>                   'UPSTREAM_CHECK_URI',
>                   'UPSTREAM_VERSION_UNKNOWN',
> +                 'UPSTREAM_STABLE_RELEASE_REGEX',
>                   'RECIPE_MAINTAINER',
>                   'RECIPE_NO_UPDATE_REASON',
>                   'RECIPE_UPSTREAM_VERSION', @@ -1180,12 +1190,13 @@ 
> def get_recipe_upgrade_status(recipes=None):
>                      data_copy.setVar(k, data.getVar(k))
>
>              data_copy_list.append(data_copy)
> +            stable_copy_list.append(stable_upgrade)
>
>              recipeincludes[data.getVar('FILE')] = 
> {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')
> }
>
>      from concurrent.futures import ProcessPoolExecutor
>      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> +        pkgs_list = executor.map(_get_recipe_upgrade_status, 
> + data_copy_list, stable_copy_list)
>
>      return _group_recipes(pkgs_list, 
> _get_common_include_recipes(recipeincludes))
>
> --
> 2.34.1
>

Hi Daniel,

I don't have any strong preference. I'll respect TSC's decision and if there's anything that needs me to do, I'll do it.

My major focus, as replied to Alex in other email, is to go through oe-core and meta-openembedded once these patches get merged. I expect that the UPSTREAM_STABLE_RELEASE_REGEX meta data will be in good shape in one or two months. And Yocto LTS releases (future ones can maybe the current ones if the backport happens) can make use of these meta data.

P.S.
I saw the changelog changes and I like it.

Regards,
Qi

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@gmail.com> 
Sent: Wednesday, May 13, 2026 5:52 PM
To: Daniel Turull <daniel.turull@ericsson.com>
Cc: Chen, Qi <Qi.Chen@windriver.com>; openembedded-core@lists.openembedded.org; MacLeod, Randy <Randy.MacLeod@windriver.com>
Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

On Wed, 13 May 2026 at 11:44, Daniel Turull <daniel.turull@ericsson.com> wrote:
> I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.
>
> Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.
>

Just in case, I support the backport. The changes to bitbake/core are not invasive, and they're in relatively 'safe' parts of the code that aren't used in core workflows (e.g. actual builds aren't affected, only the version checks and even there it's backwards compatible).

Alex