Commit graph

1 commit

Author SHA1 Message Date
671f64ca56 feat(branding): Dragon Fork identity for v0.1.0-dragonfork release
Some checks failed
tests / build (push) Failing after 2s
tests / build (pull_request) Failing after 2s
M5 / final M2-stack work. The fork now identifies itself unambiguously
in logs, the API, and the README without changing the Go module path
(internal imports stay at github.com/datarhei/core/v16 — see NOTES.md
for the rationale).

Identity surfaces:

- app/version.go gains Variant ('dragonfork') and Fork ('Datarhei —
  Dragon Fork') as vars (overridable via -ldflags for downstream
  re-packagers).
- api.About + the /api endpoint expose 'variant' and 'fork' fields;
  Swagger docs regenerated.
- Startup banner logs 'variant' + 'fork' alongside the existing
  application + version fields, so a TrueNAS sysadmin tail-following
  /var/log can tell at a glance which fork is running.

Documentation:

- README.md rewritten with a Dragon Fork header and Quick start; the
  upstream feature surface is summarised in 'From upstream Datarhei'
  with a clear additivity statement. Sample process JSON, multi-input
  pipeline guidance, link to the design + testing docs.
- NOTICE: Apache 2.0 §4(d) attribution to upstream datarhei Core,
  Pion, Echo, FFmpeg.
- CREDITS: enumerated dependency list with licenses.
- CHANGELOG.md prepended with a 'Datarhei — Dragon Fork' section
  starting at v0.1.0-dragonfork; upstream's '# Core' history preserved
  below.

Module path stays github.com/datarhei/core/v16 by design — the fork is
distinguished by repo location and branch history, not import path.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-03 12:22:25 +00:00