Development and Releases

Develop and contribute

The supported development platform is Linux amd64 with the pinned Go toolchain and the standard build tools listed in CONTRIBUTING.md. The routine checks are:

make ci-test
make ci-vet
make ci-build
make ci-package
make ci-local

Run focused package tests while changing code, then use the full set before opening a pull request. Generated protocol and SQL code must be regenerated and committed when their source changes. See the CI guide and architecture guide for ownership boundaries.

Releases

Debuglet follows semantic versioning and keeps release notes in CHANGELOG.md. A release tag must point at a reviewed, tested main commit. Build the package from a clean checkout and verify its checksum manifests. Published v0.2.0 has three full-bundle assets: its archive, installer and checksums. Newer source builds also produce separate CLI, executor and dispatcher archives with their own installers and checksums; publish those alongside the full bundle when releasing that version. Include the compatibility sidecar when the selected build produces it. The installation reference lists the exact component filenames.

A development archive named v0.0.0-dev.<revision> is not a versioned release payload. Build from the selected release tag using the supported release build environment; verify the version and source revision inside every archive before publication. Deploy only through the explicit upgrade procedure.

Do not equate a GitHub release with a production rollout. Deployment requires a separate, reviewed action in the environment that can reach the hosts, plus post-deploy health and measurement verification.

Open an issue for bugs, features, and operator documentation gaps. Report vulnerabilities privately using the security policy.