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

108 lines
6.1 KiB
Markdown
Raw Normal View History

# Release preparation (0.1.0 development prototype)
Phase 9 makes source packaging, staged install/uninstall and repeatable builds
testable. It does not turn the prototype into a production-qualified DAW. The
version remains 0.1.0; no tag, external release or binary publication is created
by `make dist` or `make release`.
## Build and package
```sh
make release
make test-install
make test-recovery test-performance
make dist
make test-release
```
release builds optimized, warning-enabled C/C++ code, tests and the optional GUI
in BUILD_DIR/release with no debug paths, a source-prefix map, deterministic ar
metadata and FLTK include/define flags rather than distribution-specific LTO
flags. It retains assertions so the test harness actually runs. dist creates
BUILD_DIR/xtc-0.1.0.tar.gz using Python's standard library. It includes only Git
indexed regular files (working-tree contents, including staged new files), plus
a source manifest; stage intended files first and check `git diff --cached`.
Untracked files, ignored build output and .git are excluded. Exported archives
can reproduce themselves without Git using SOURCE_MANIFEST.json.
Archive order, permissions, ownership, gzip filename and timestamps are normalized.
SOURCE_DATE_EPOCH defaults to 0; set an unsigned 32-bit epoch explicitly if desired.
The archive does not claim to identify a commit: release from a clean checkout
and record its commit/hash externally. Do not treat a dirty-tree archive as an
attested release. No artifact is uploaded by these targets.
test-release unpacks the source into two different temporary paths, runs release
in each, compares libxtc.a/xtc-check/optional xtc SHA-256 values, and repacks each
export to compare archive bytes. This verifies reproducibility for the same host,
compiler, flags and dependency versions. It does not promise bit-identical output
across distributions, compilers or library updates. Compiler/debug/sanitizer
build directories are intentionally separate; changing toolchain/flags in place
requires a clean directory. Python release tests require version 3.12+.
## Qualification record
Run normal core/GUI and live software JACK tests, no-JACK builds and ASan/UBSan.
GUI leak tests retain the narrow fontconfig suppression; core tests do not.
TSan recorder/publication tests complement lifecycle tests. Native API tests
verify callback failures, cleanup and retirement; they cannot certify arbitrary
extensions. See BUILD.md and tests/integration/README.md for commands.
Record versions, archive hashes, installation/consumer checks and measured timing.
Use LICENSES.md for dependency/license review and PLUGIN_HOSTING.md for the
external-hosting decision. Review RECOVERY.md for migration and process-crash
semantics. Physical devices, power loss, sustained recording/performance, user
acceptance on other distributions and binary redistribution are still separate
qualification work. There is no DEB/RPM/AppImage, bundled runtime, autosave,
external plugin host or stable shared-library extension ABI in this release.
## Phase 20 local binary packaging and installed workflow
`make test-package` builds the release, stages installation only in a temporary
DESTDIR, writes a normalized Linux binary/development archive, checks its SHA-256
sidecar and per-file manifest, relocatable pkg-config paths and headless commands.
Same-host repeated packaging is byte-identical; dependency versions and toolchain
still determine binary compatibility. `make test-install` now repeats installation
to verify repair/upgrade of owned files while preserving an unrelated sentinel,
then compiles both C99 and C++17 installed consumers that create MIDI, save/reopen
and compare nonzero exact rendering. Removal remains exact and idempotent.
USER_MANUAL.md consolidates operation; KNOWN_LIMITATIONS.md lists qualification
gaps; MAINTENANCE.md defines the release checklist, regression and compatibility
policy. Build diagnostics make no server/plugin calls. There is no asynchronous
crash uploader or signal-handler cleanup: inspect OS core/debugger evidence on
the control side, preserving project/media recovery paths. No release is publicly
published by these commands, and human/device/listening checks remain pending.
## Phase 30 release workflow
Installation now shares one explicit file inventory with uninstallation. GNU-style
`exec_prefix`, `bindir`, `libdir`, `includedir`, `datarootdir`, `datadir`, `docdir`,
`pkgconfigdir` and the xtc-specific `licensedir`, `examplesdir`, `desktopdir` can be
overridden alongside `PREFIX`/`DESTDIR`. Paths must be absolute POSIX paths;
spaces are supported. Do not include DESTDIR in a directory variable: staging is
applied separately and never embedded in pkg-config metadata. Staging refuses
parent symlinks that escape DESTDIR. Use exactly the same variables for removal.
```sh
make BUILD_DIR=build/release-check all test gui
make BUILD_DIR=build/release-check test-install test-install-layout
make PREFIX=/usr DESTDIR=/tmp/xtc-stage libdir=/usr/lib64 install-gui
make PREFIX=/usr DESTDIR=/tmp/xtc-stage libdir=/usr/lib64 uninstall
make test-release test-package
```
Core install includes the static library, public headers, `xtc-check`, pkg-config
metadata, Markdown documentation, all checked-in performance reports, license and
`share/xtc/examples` (a media/plugin-free MIDI demo). GUI install adds the desktop
entry and `xtc`. No desktop MIME association is claimed. Package archives keep
their fixed `/usr` layout and relocatable pkg-config metadata; custom live layouts
are tested separately. Existing owned file symlinks are replaced, not followed;
installation is atomic per file, not a transaction over the entire prefix.
`make dist` now writes a `.sha256` sidecar as well as the normalized source archive.
Record that hash, the reviewed commit, version and build/dependency conditions
with release logs. `test-release` verifies the hash, builds/tests two fresh source
exports and compares artifacts and repacks. It validates exported tracked content,
including staged work; it does not attest that the caller's Git tree is clean.
For public release use a clean reviewed checkout and inspect `git status` first.
RELEASE_NOTES.md supplies upgrade guidance and remaining qualification limits.