ADR-1868: Fold the 2026-10-05 scope into the existing RC4 to RC9 candidates¶
- Status: Accepted
- Date: 2026-10-05
- Deciders: maintainer
- Tags: release, rc, roadmap, process
Context¶
ADR-1490 fixed the first-release candidates RC3 to RC9, and ADR-1829 put the device-memory import API into RC4. On 2026-10-05 more work joined v1.0.0: the new VMAFx C API with generated surfaces and the VMAFx-named FFmpeg filters (ADR-1852, #2176), provenance on every score (#2142), tool consolidation (#1249, #1250, #1270, #1272), new metrics with device twins (#1247, #1248, HDR-SSIM / HDR-MS-SSIM #2161, XPSNR #2158), Metal twins for the SpEED extractors (#2160), and training readiness: data hygiene (#2163, #2157), evaluation tooling (#2162, #2143), the HDR conversion-check workflow (#2145) and a mini retrain with a measured resource plan (#1246). The maintainer asked whether the candidates after RC4 had to be redesigned, and decided to fold the work into the existing candidates instead of adding numbers.
Decision¶
The candidate numbers and their order stay; their scope grows:
| Candidate | Owns | Epic |
|---|---|---|
| RC4 | The vmaf_v1.0.16_3d0h path in Rust; the device-memory import API (ADR-1829); the new VMAFx C API, its generated surfaces and the VMAFx FFmpeg filters (ADR-1852, #2176); provenance on every score (#2142) | #1723 |
| RC5 | Deduplication and libgpudispatch (#1455); tool consolidation (#1249, #1250, #1270, #1272); the new metrics with exact twins written once on libgpudispatch (#1247, #1248, #2161, #2158); Metal twins of speed_chroma / speed_temporal (#2160) | #1724 |
| RC6 | The GPU capability table, now covering the RC5 twins | #1725 |
| RC7 | The CPU capability table (unchanged) | #1885 |
| RC8 | Benchmarks, profiling and tuning, plus training readiness: data hygiene (#2163, #2157), evaluation tooling (#2162, #2143), the HDR conversion-check workflow (#2145), the mini retrain and the measured resource plan of #1246 | #1245 |
| RC9 | The one-shot retrain and the remaining tiny-AI training; its preconditions list every item above | #1246, #1242 |
Final v1.0.0 still follows accepted RC9 evidence. The phase rules of ADR-1341 and ADR-1490 stand: benchmarks and tuning never in RC3 to RC7, training never before RC8 evidence is accepted, speed lost to exactness recovered in RC8. New twins in RC5 meet the RC3 exactness rule (bit-identical to the CPU extractor, or a measured libm bound recorded in an ADR). This ADR refines ADR-1490 (the scope of RC4, RC5, RC6, RC8 and RC9) and ADR-1829 (RC4 also holds the new API, the filters and provenance); it supersedes neither.
Alternatives considered¶
| Option | Pros | Cons | Outcome |
|---|---|---|---|
| Fold into the existing candidates (chosen) | Numbering, issues, milestones and the tester catalog stay; each item sits where its dependency is (new twins on libgpudispatch, readiness before the one-shot retrain) | RC4, RC5 and RC8 grow | Chosen |
| New candidate numbers for the API and for the new metrics | Smaller candidates | Shifts RC5 to RC9 a second time (ADR-1490 did once); the new twins would be written before libgpudispatch and then again on it | Not chosen |
| Keep the new metrics and HDR work after 1.0.0 | Smaller first release | The one-shot retrain could not use them, so it would have to be repeated | Not chosen |
Consequences¶
- Positive: one map for every 1.0.0 item; the retrain runs once, with every tool and feature it needs already in place.
- Negative: RC4, RC5 and RC8 carry more work and more exit evidence.
- Neutral / follow-ups: the RC issues and milestones were updated on 2026-10-05;
AGENTS.md§11,docs/roadmap.md,docs/development/release.mdand the dispositions table ofdocs/state.mdfollow this map (T-GAP-METAL-MISSING-SPEED-TWINSmoves from RC8 to RC5).