4.0 (2026-07-26)

Introducing releng_config

With this release of releng-tool, a newer/alternative way to configure project-specific options has been added. The releng_config call can be used in the project configuration (releng-tool.rt) which accepts all supported project options. For example:

releng_config(
    packages=[
        'package-a',
        'package-b',
        'package-c',
    ],
    environment={
        'MY_ENV': 'Example value',
    },
    url_mirror='ftp://mirror.example.org/cache/{name}/',
)

The goal of this call is to provide a grouped/concise configuration definition for releng-tool-specific options. A project configuration can include both releng-tool options and other developer-defined additions (e.g. custom argument handling, build sanity checks, etc.). Having a releng_config call may help users easily distinguish between releng-tool options versus other implementation.

Python packages will implicitly use PEP 517 building

Historically, Python packages in releng-tool defaults to a distutils build. This was later dropped due to the deprecation/removal of distutils package; and packages required an explicit LIBFOO_PYTHON_SETUP_TYPE set.

As of 4.0, support has been re-added for having an implicit setup type configured. For Python packages without a setup type set, it will be assumed the package supports a PEP 517 build. This will invoke the build module and trigger the configured backend in a Python project’s pyproject.toml file.

Support for forced-revisions from the environment

Typically, most project options and package variables can only be externally set using variable injection. This release brings flexibility when using the LIBFOO_FORCE_REVISION package option by allowing it to be pulled from the default running environment.

For example:

export MY_APP_FORCE_REVISION=1.2.3
releng-tool

Note that the environment values are ignored when operating in a „release mode“.

Removals

The following deprecated feature have now been removed:

• Support for .releng extension has been dropped