M5: Dragon Fork branding + v0.1.0-dragonfork #10
Loading…
Reference in a new issue
No description provided.
Delete branch "m5-branding-release"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Last milestone: project identity + first tagged release.
Identity
app/version.gogainsVariant("dragonfork") andFork("Datarhei — Dragon Fork") asvars — overridable via-ldflagsfor downstream re-packagers.api.About+ the/apiendpoint now exposevariantandforkfields; Swagger docs regenerated.variant+forkalongside the existingapplication+versionfields, so tail-following/var/logmakes the fork unmistakable at a glance.github.com/datarhei/core/v16by design — the fork is distinguished by repo location + branch history, not import path. (Documented inNOTES.mdsince M1 baseline.)Documentation
README.mdrewritten — Dragon Fork header, sample process JSON, multi-input pipeline guidance, links to the design and testing docs. Upstream feature surface summarised under "From upstream Datarhei" with an explicit additivity statement.NOTICE— Apache 2.0 §4(d) attribution (upstream Datarhei Core, Pion, Echo, FFmpeg).CREDITS— enumerated dependency list with licenses.CHANGELOG.mdprepended with a "Datarhei — Dragon Fork" section starting atv0.1.0-dragonfork; upstream's# Corehistory preserved below.Release
After this lands on
main(post-merge of M2 + M3 + M4 + M5), tagv0.1.0-dragonforkand create a Forgejo Release pointing at the same commit.Files
Stack
Targets
m2-webrtc-core-integrationso it lands without depending on M3/M4 PRs. The branding is independent of the WebRTC robustness and CI work; the merge order can be M2 → M3 → M4 → M5 or any other sequence the reviewer prefers.Co-authored with Claude Opus 4.7.
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>Merged into
mainvia direct push as part of the v0.1.0-dragonfork release. Branch commits are reachable from main; closing this PR. Release: https://forge.wilddragon.net/zgaetano/datarhei-dragonfork-core/releases/tag/v0.1.0-dragonforkPull request closed