Link Search Menu Expand Document

VOXL SDK Configuration Management

Table of contents

  1. Overview
  2. Configuration Identification
  3. Change Control
  4. Release Process
  5. Traceability and Reproducibility
  6. Related Pages

Overview

This page summarizes how ModalAI manages software configuration for the VOXL SDK: how software is identified and versioned, how changes are controlled, how releases are assembled and tested, and how a released configuration is preserved so that any fielded system can be traced back to an exact, known set of software. This process applies to all VOXL SDK releases, including the SDK 1.6 series.

Configuration Identification

A VOXL SDK release consists of three configuration-controlled elements:

  1. Software packages — every SDK component (services, libraries, tools) is an individually versioned Debian package. Source code for each package is maintained in its own Git repository at https://gitlab.com/voxl-public, and each released package version corresponds to a tagged commit in that repository.
  2. The voxl-suite meta package — the top-level configuration item that defines an SDK release. A stable voxl-suite release declares exact (==) dependency versions for every package it contains, so a given SDK release is a fully enumerated, immutable set of package versions. The SDK release takes its version number from voxl-suite.
  3. The system image — the base operating system image, versioned independently and paired with each SDK release (for example, SDK 1.6.3 on the QRB5165 platform pairs with system image 1.8.06). See the system image release notes.

Every SDK release is published with release notes that enumerate the complete package list, the exact version of each package, and the version delta from the previous release, along with MD5 hashes of the release installers so a downloaded artifact can be verified.

Version numbering follows a major.minor.patch scheme. Patch releases (e.g. 1.6.2 to 1.6.3) are in-place package updates against the same system image; minor releases pair with a new system image and are installed by a full system flash.

Change Control

All SDK source code is managed in Git on GitLab. Changes land on a package’s mainline branch via GitLab merge requests, giving every change a reviewable, attributable history.

Every commit to every package triggers an automated GitLab CI build. Packages are built inside version-controlled Docker build environments, so the toolchain used to produce a package is itself configuration-controlled and builds are reproducible. A commit that fails CI does not produce a package.

Built packages then flow through a tiered repository structure at http://voxl-packages.modalai.com/dists/, described on the package manager page:

TierContents
devPer-commit CI output from the development branches. Nightly SDK builds, paired with nightly system image builds, are assembled from this repository. Internal use.
sdk-x.yRelease sections for each SDK version. Alpha, beta, and full SDK releases are built from these sections, and their contents change only as part of a tested release.

Promotion from dev into a release section is deliberate: a package version reaches an SDK release only by being pinned into a voxl-suite release, and each full release is preceded by alpha and beta releases built from the same sdk-x.y section and gated by the release testing described below. Alpha releases are used internally; beta releases are provided to customers upon request for early validation ahead of the full release.

Release Process

Stable SDK releases are assembled and gated by a release manager. The release cycle consists of:

  1. Candidate assembly — the release manager pins the candidate package versions into voxl-suite, pairs the suite with its system image, and produces candidate SDK installers.
  2. Continuous exercise — throughout the release cycle, nightly full-SDK builds (assembled from the development repository alongside nightly system image builds) are flashed onto hardware and exercised, so integration problems surface early rather than at release time. Nightly builds are also available to customers upon request.
  3. Release regression testing — alpha and beta release candidates are flashed to each supported hardware platform (VOXL 2, VOXL 2 Mini, and supported vehicle configurations) and tested against ModalAI’s internally controlled, numbered SWQA test documents, which define test procedures at the PCB, sub-assembly, and integrated drone/flight-test levels — covering boot, sensors, cameras, communications, and autopilot function.
  4. Flight testing — release candidates are flown on development aircraft to verify integrated, real-world behavior before release. Flight logs are collected for every test flight and reviewed internally.
  5. Sign-off and publication — once testing passes, the release manager signs off and publishes the release: installers (with MD5 hashes) to the ModalAI developer portal, the frozen sdk-x.y package repository section, and release notes with the full package list and changelog.

Traceability and Reproducibility

The released configuration is traceable end to end:

  • The published package list for a release maps every installed package version to a tagged commit in its public GitLab repository, where its full development history is available.
  • The software configuration of any fielded VOXL can be audited by comparing its installed package versions (dpkg -l) against the published package list for its SDK release.
  • Release installers are verifiable against published MD5 hashes.
  • Prior SDK releases and their package repository sections remain published, so any previously fielded configuration can be retrieved and reproduced.

ModalAI recommends operating on stable SDK releases as delivered, since they are tested as a whole (packages plus system image together). The package manager configuration that would point a system at development repositories is opt-in and not used on fielded stable systems.