0.14 (2023-02-05)

Removal of the deprecated releng namespace

It has been over two years since the switch from the releng namespace to the releng_tool namespace. Projects using the obsolete namespace for project scripting support will now be required to update there scripts to use the most recent version of releng-tool. For projects which still may be using the obsolete namespace, changes should be as simple as changing implementation such as:

from releng import releng_execute

to:

from releng_tool import releng_execute

All calls supported in the previous namespace will be available in the new namespace.

Software build of materials

Projects will now automatically generate a software build of materials (SBOM) at the end of a build. This can be helpful for environments which want to have a summary (and even parsable) description of the package components used, their versions, licenses and more. Users can find SBOM documents in the configured output folder after a build.

Various SBOM formats are supported. For example, users wanting to generate a JSON SBOM output can use the --sbom-format json argument on the command line. Generating an SBOM for a project does not require a build, if desired – users can generate an SBOM by using the action sbom on a project. For example:

$ releng-tool sbom

Promotion of SPDX license identifiers

It is now recommended to use SPDX license identifiers for package licenses. The goal is to help promote the use of standardized short identifier for license entries, which can be helpful for environments wishing to process SBOM output of a releng-tool project for license analysis.

When a package license is configured and the value does not match a SPDX license identifier, a warning will be generated. Warnings will also be generated when using deprecated identifiers as well.

If a package is required to use a license string that is not a listed SPDX license identifier, extra license and exception identifiers can be registered in the project’s configuration script. See the extra_licenses and extra_license_exceptions configuration options for more details.

Note that releng-tool will not generate a warning if the license value Proprietary is provided.
Edit: As of v1.1+, we no longer a Proprietary marking; use a license identifier field instead.

New environment/script variables

This release includes the *_BIN_DIR environment/script variables. These can be used to allow a developer to reference specific bin paths for the host, staging or target areas. The following lists the newly added variables:

  • HOST_BIN_DIR (e.g. <host-dir>/usr/bin)

  • STAGING_BIN_DIR (e.g. <staging-dir>/usr/bin)

  • TARGET_BIN_DIR (e.g. <target-dir>/usr/bin)

New move-into script function

The releng_move_into helper function has been added to allow releng-tool script to explicitly move a source into a target directory. This can be helpful for users who wish to avoid scenarios using releng_move and needing to ensure the destination directory exists or avoiding the need to add a trailing file separator at the end of the destination target. An example of this new call is as follows:

releng_move_into('my-file', 'my-directory')

Support for Poetry Python setup type

The previous release of releng-tool introduces support for processing Python packages using various common setup types. This release extends on this by adding support for Poetry.

For example:

LIBFOO_TYPE = 'python'
LIBFOO_PYTHON_SETUP_TYPE = 'poetry'