Skip to content
This repository has been archived by the owner on Jul 19, 2024. It is now read-only.

Latest commit

 

History

History
61 lines (33 loc) · 4.69 KB

release.md

File metadata and controls

61 lines (33 loc) · 4.69 KB
Raw

Release Processes

As per the Versioning and release process of the libs artifacts, this repository includes different groups of artifacts that needs to be versioned and released. Moreover, those artifacts follows different versioning schemas (see the Driver SemVer and Versioning schema) proposals).

We have two separate release processes which occur independently of each other:

  • The drivers release
  • The libs release (ie. libsinp and libscap)

The drivers versioning process happens in this repository, but their release process is mainly automated and managed in our test-infra. Building is implemented there as per the Driverkit Build Grid, and drivers are published to https://download.falco.org/?prefix=driver/.

Note that not all versioned releases will be built and distributed. Drivers distribution is indeed implemented and maintained only to satisfy Falco's needs.

The libs release process is currently under development and limited to the versioning process only. The libs versioning process happens in this repository.

Release procedure

Regardless if it is a driver or a libs release when initiating a new release, we do the following process:

  1. We decide together (usually in the #falco channel in slack) if the source code is in a shape good enough to be released
  2. We double-check if the versioning rules have been respected (see sections below), then we pick the next version number to tag (i.e., a git tag)
  3. A person with repository rights creates a new release using the GitHub UI (a git tag will be automatically created)

At the time of writing, no other steps are needed since the whole release process is still in development. This document will be updated once the definitive process is fully implemented.

Drivers versioning

The driver version number represents the build version of kernel-space drivers (i.e., the kernel module, the eBPF probe, and possibly any other kernel-space artifact).

Requirements

  • The version MUST be a SemVer 2.0 compliant string.

  • Since our driver APIs are assumed to be stable, the major version number MUST be equal to or greater than 1.

  • The version string MUST be suffixed with +driver to distinguish it from libs version numbers.

  • To pick a new driver version number:

    1. The API for user/kernel boundary is versioned in the source code. You MUST ensure the two files below have been updated by following the rules described in driver/README.VERSION.md:

      If not, open a PR to fix them.

    2. Compute the driver version number by strictly following the Versioning Schema proposal's rules.

Note that API_VERSION and SCHEMA_VERSION are only used internally. On the other hand, only the driver version number will be used to tag a new release.

Libs versioning

The libs version number represents a software version of the user-space libraries (i.e., libscap, libsinsp, and possibly any other further user-space library), and it is not tied to the drivers version numbering.

Requirements

  • The version MUST be a SemVer 2.0 compliant string.

  • Since our userspace APIs are not yet stable, the major version number MUST be 0 (see the SemVer section about the initial development phase).

  • The Plugin API is versioned in the code and follow a semver-like numbering scheme. If any changes have been made to the Plugin API since the last release, you MUST ensure the Plugin API version is updated accordingly. If not, open a PR to fix it.