1
0
Fork 0
forked from hanez/xtc
xtc/docs/MAINTENANCE.md

3.4 KiB

Release and maintenance policy

Supported development target

Initial target: x86_64 Artix/Arch-family Linux with glibc, GNU Make, GCC/Clang, FLTK 1.4 and a JACK-compatible client/server. The inspected host uses GCC 16.2.1, FLTK 1.4.5 and the dependencies in LICENSES.md. Core-only/no-JACK/no-LADSPA builds are checked too. Build on the destination distribution for different library ABIs; there is no cross-distribution static-binary promise. Python 3.12+ and binutils are build/package/test tools only. No dependency is fetched automatically.

Release checklist

  1. Work from a clean reviewed commit. Record git rev-parse HEAD, compiler, libc/FLTK/JACK versions and xtc-check --diagnose. No automatic version bump, Git tag, public upload or external release is performed by local targets.
  2. Run warning-enabled make all test gui test-plugins test-plugins-real test-gui-plugins test-workflow test-gui-jack test-jack-midi test-recording test-recovery test-reliability test-scale analyze where dependencies exist.
  3. Use a separate BUILD_DIR for ASan/UBSan/leak runs and another for optional- dependency builds. GUI leak checks use only the documented fontconfig suppression; core tests use none. Run publication/recording race tests as described in RELIABILITY.md. Sanitizers are not latency qualification.
  4. Run make benchmark test-performance test-stress; compare on matching host/compiler/flags against a reviewed baseline. Investigate regressions; do not weaken thresholds or replace evidence without explanation.
  5. Run make test-install test-release test-package. Inspect archive manifests, hashes, dynamic dependency names and licenses. Source exports rebuild twice with identical artifacts on this host. Repeat binary packaging compares bytes.
  6. Complete physical listening, recording/device/endurance, and independent human install/workflow checks before claiming production qualification. They remain pending for this prototype, even when all automated checks pass.
  7. Save checksums/test logs/conditions with the proposed release. Review known limitations and format compatibility and update user/developer docs. Publishing or distro repository submission is a separate action.

Regressions and compatibility

Report the exact version/commit, OS/toolchain, compiled features, reproduction, expected/actual output, GUI errors/xruns and whether plugins are involved. Keep a minimal project/media fixture when redistribution is permitted; do not attach private recordings or full memory dumps inadvertently. No telemetry/upload occurs.

A confirmed defect gets a focused deterministic regression or repeatable runtime check before its fix. Memory/thread/file-loss defects take priority; disable the unsafe path rather than silently dropping media or unknown project records. Keep candidate preparation/plan publication transactional and callbacks bounded.

Format changes increment XTC_PROJECT_FORMAT_VERSION, retain explicit bounded migrations/fixtures for all supported older versions, and add malformed/roundtrip checks. Unknown versions/types/records fail with actionable errors. Never rewrite an unsupported source file during failed Open. Keep the original when diagnosing post-publication sync errors. Native descriptor ABI compatibility is distinct from project format and is documented in NATIVE_API.md; opaque DSP state is not promised. No public stability guarantee or support SLA is implied by development version 0.1.0.