3.1 (2026-06-28)

Support for Xmake package types

Introduction of the xmake package type for Xmake-based packages. This new package type allow a developer to easily invoke Xmake calls at various stages without needing invoke these tools inside a scripts package.

Support for Lore sites

With this release, releng-tool now supports cloning from Lore instances. In a host environment with Lore client installed, releng-tool runs can clone from this version control system when a Lore-compatible site is provided:

LIBFOO_SITE = 'lore://lore.example.org/my-project'

Support release mode invoked runs

Users can now invoke releng-tool in a „release mode“. It can be used to sanity check a run is using a runtime configuration appropriate for a release. This mode can be enabled using the --release argument. For example:

releng-tool --release

What a release means for developers may vary, but there are some options releng-tool can determine that should not be applied for a typical release. A series of checks are performed. In the event that a check detects a runtime configuration state that should not be used for a release, releng-tool will stop.

Checks performed include:

Support network isolation for package’s non-fetch stages

Developers can now configure projects to run in a network isolation mode for non-fetch stages. This helps promote the use of using only fetch-related stages to acquire remote sources, and help support capabilities such as offline builds.

Network isolation mode can be configured at the project-level using the network_isolation project configuration:

network_isolation = True

Developers may also tailor individual packages for network isolation mode using the LIBFOO_NETWORK_ISOLATION option.

Introducing releng_step helper script generator

To help the user experience for developers wishing to easily perform sub-stage actions for large packages, a new script helper releng_step has been introduced.

Packages will process various stages for configuration, build and so on. Once a stage is complete, re-runs will step over already completed stages. This works at a package-level, but developers processing monolithic packages may attempt to internally mange their own stages for large sections of work. This may include checking and setting custom file flags.

Developers can now use a provided releng_step generator to help limit actions in a stage to only occur once. Consider the following example added into a project’s build stage script:

for _ in releng_step('part-one', force=RELENG_REBUILD):
    # invoked only once on success

for _ in releng_step('part-two', force=RELENG_REBUILD):
    # invoked only once on success

for _ in releng_step('part-three', force=RELENG_REBUILD):
    # invoked only once on success

This package performs three sub-stages for its build. In the event that „part-two“ fails to build; a developer may then investigate, correct and re-start the build process. Since „part-one“ has already been performed, its context will be skipped, avoiding any unnecessary extra build actions.

Planned Removals Next Release

The following features are planned to be removed next release:

  • Support for the .releng extension