Skip to content

development-and-releases.md

Latest commit

 

History

History
40 lines (25 loc) · 4.53 KB

development-and-releases.md

File metadata and controls

40 lines (25 loc) · 4.53 KB
Raw

Development and release engineering

Status: experimental native implementation. C++20/CMake, owned DSP/GPS handling and pinned source inventories are in use. Public source and experimental Apple Silicon macOS and Ubuntu 24.04 packages are available through GitHub Releases. The macOS release uses Developer ID signing and Apple notarization. Windows packaging, minimum-OS acceptance and full physical-device qualification remain unfinished. There is no application auto-updater.

Development lifecycle

  1. Resolve requirements and architectural decisions, then make one logical change on an appropriate branch.
  2. Review dependency/source provenance and retain licenses; normal builds use existing inputs without downloads.
  3. Keep builds and tests in ignored build directories, with operational data excluded from Git.
  4. Run relevant checks and record actual results and limits. Device tests require separate authorization.
  5. Update affected behavior, security, support and deployment documentation in the same change.
  6. Review staged contents, secrets, Git identity and generated files before committing or proposing publication.

Current build instructions, dependency inventory, OpenSSL intake and UI validation provide the concrete inputs and evidence. Reproducible instructions are not a claim of demonstrated bit-for-bit builds. The normal application does not require Python/protoc; optional generators and developer tests remain separate.

Source publication

Follow the GitHub preparation checklist. Publish only a reviewed source snapshot or a separately approved sanitized history. Preserve existing local history and private recordings; never push all branches or mirror this checkout without a history/privacy review. No remote operation is authorized by preparing files.

A source release includes build inputs, tests, current documentation, copyright/license notices and provenance. It excludes local Git metadata, machine inventories, downloaded review copies, compiled output, operational data and private working instructions. Use the reviewed publication manifest and a single starting commit for an initial snapshot.

Binary releases

A development source version is not a supported binary release. Before distributing executables, complete:

  • A tested OS/architecture/receiver and driver matrix, known limitations and install/uninstall instructions.
  • Exact dependency closure and matching Corresponding Source, including applicable LGPL replacement/relinking requirements, generated schemas, patches and build/install scripts.
  • Clean-machine packaging tests, signatures/notarization where applicable, artifact hashes and a release-specific component inventory or SBOM.
  • RF/endurance, GPS and protocol compatibility evidence appropriate to the claims, plus storage/preferences compatibility and rollback instructions.
  • Named security/release/support ownership and realistic supported-version and response policies.

Release bundles use the reviewed repository-local USB libraries and include a replaceable shared libusb. RAK builds must also include the matching ovmesh-rak-worker beside the main executable; source/license manifests cover its pinned HAL. Linux container installation and synthetic launch checks pass for the published packages; physical Linux hardware acceptance and Windows release packaging remain unfinished. Windows RAK operation is not implemented. No signing key, certificate or release token belongs in Git. Platform signing/notarization uploads require explicit authorization.

Updates and rollback

Updates are explicit reviewed project changes. There is no application auto-updater or floating startup dependency installation. Track fixes for copied code as well as linked libraries; do not present a pinned version as permanently secure.

Keep old session readers available and use isolated preferences with older binaries. New session writes do not migrate existing files. For code rollback, preserve current work and use an appropriate retained branch or separate checkout instead of destructive resets. See build isolation and format compatibility before changing application versions.

Release ownership remains tracked in governance. Public GitHub source publication and a supported application release are separate decisions.