Add RDK-E component release context to Brick Model
Add whitepaper: The Brick Model — how the RDK stack is built, versioned, tested and released Picture-led explainer for product and programme readers, linked from the Start here table on Home. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DJfdKzj1ELpcXQeGVQo9yW
BLD-6 is met by halcompat::isCompatible(); diagram says where a mismatch is rejected
Make requirement IDs clickable: anchor each row, link every reference
Link every open ticket; BLD-5 met (linux_binder_idl#62 fixed by PR #63)
Say released, not frozen: every version is released the same way; the era changes the compatibility rule
VER-5 is met; build files out of the snapshot are VER-9 (#828)
Fold the requirements into HAL Version Use Cases; remove the separate page
Add HAL Version Requirements (draft); tag each use case with its requirements
Add HAL Version Use Cases; write the Presentation skew diagram in 4-part versions
Update Trade Study: Metric Key Set — how it is carried
Add Trade Study: Metric Key Set — Android HAL evidence
Updated Presentation: The AIDL build system — what we freeze, and how it is consumed (markdown)
Drop the in-body H1 where it repeated the page title The wiki renders the file name as the page heading, so a leading H1 that restated it showed the title twice. Home keeps its H1, because there the heading is the real title and the file name is not.
Trade study: drop the in-body H1, the page title comes from the file name The wiki renders the file name as the page heading, so a leading H1 in the body produced the title twice.
Trade study: three-position semantic versioning for a vocabulary Each position is defined by the compatibility rule it corresponds to: major for a removal or a change of meaning, type, unit or kind, minor for an addition, patch for documentation. A floor holds within a major, so the major position is where a vocabulary is permitted to break.
Trade study: show the directory layout, so how a vocabulary releases and how an interface releases are each visible An interface release cuts a new a.b.c.d/ directory and writes a .hash. A vocabulary release creates a new kvc/x.y/ directory and touches neither. Also records that a frozen interface version does not name the vocabulary revision it requires.
Add trade study: where the metric key set lives, and what each option costs Three ways to carry a metric key set, weighed against six criteria. Includes the Android stats history measured per producing module, the effort for each option, and the decisions the group is asked to take before the metrics surface freezes.
Whitepaper: add diagrams for the four arguments a product reader has to hold Add-only growth and what it forbids; the second interface published beside the first and the consumer migrating on its own schedule; the freeze window from pre-freeze through to production; and the missing platform layer, drawn as the two destinations a change can take when it is too large to add. All four validated with mmdc. Mermaid is already enabled in mkdocs.yml via pymdownx.superfences, so these carry over unchanged when the paper lands in docs/whitepapers/ under #830.
Whitepaper: state the freeze intent; Home: stop linking into the 2025 docs build Whitepaper previously implied we were in no hurry to freeze. The position is the opposite: interfaces freeze as early as they responsibly can, and all of them before production, with the last pre-freeze version becoming the first frozen version unchanged. That also sharpens why the platform-major decision is urgent rather than theoretical - a clean break is cheap only while everything is still pre-freeze. Home linked to /introduction/interface_generation/, which is served by an unversioned June 2025 build still sitting at the gh-pages root rather than by any released version. Point the build instructions at the source on develop, keep the docs-site link at the root so it follows the latest release, and say which one wins when they disagree.
Add product whitepaper: backwards compatibility, its cost, and the platform major decision Explains for a product audience what freezing an interface promises, why the promise permits only additions, what publishing a second interface costs, and why we remain pre-freeze by design. Raises the gap it exists to raise: the rules govern individual interfaces, and nothing defines where the platform itself is allowed to break. Asks product to define what an RDK major release is permitted to change.
baseline version
Created Audio Mixer HAL Routing and Connectivity Test Direction (markdown)
Updated DRM HAL Vendor Conformance Test (markdown)
Created VtsHalDrmTargetTest.cpp (markdown)
Created DRM HAL Vendor Conformance Test (markdown)