Das SDK aufholen lassen, bevor es abdriften konnte

Parität, die am Anfang eines Projekts gebaut wird, kostet tausendmal weniger als Parität, die nachträglich eingebaut wird. Die Bindings von RakuAI werden gemeinsam mit der Runtime entwickelt, bei jedem PR gegattert - damit deine Binding-Wahl dich später nie von einem Feature aussperrt.

Schon nervös wegen eines bestimmten Fehlermodus, den ich schon mehrfach Multi-Repo-Projekte habe töten sehen, und das war der Ausgangszustand dieses Samstagmorgens. Die Runtime fügt an einem Wochenende ein Feature hinzu, und das SDK holt erst nächsten Monat auf. Die Beispiele in einem Binding funktionieren, und die Beispiele im anderen Binding regredieren still. Die Versionsnummern stimmen nicht mehr überein. Die CI in jedem Repo ist grün, und die Integration zwischen ihnen ist kaputt.

Dieser Film endet mit einer Neuplattformierung zwei Jahre später. So baue ich Raku nicht. Der Plan für dieses Wochenende war, das SDK auf den Stand der Runtime zu bringen, bevor die Lücke entstehen konnte, und genug Infrastruktur zu hinterlassen, damit die Lücke nie wieder entstehen kann.

Was auf der SDK-Seite gelandet ist

Das SDK hatte ein großes Wochenende. Die Runtime-Seite war ruhiger (der Großteil ihres großen Vorstoßes passierte das Wochenende zuvor, als PR #104 VIO/SLAM, den QoS-Scheduler, den Performance-Kabelbaum und die Telemetrie-Pipeline landete). Dies war das Aufhol-Wochenende für die Bindings.

Highlights:

• SDK v0.2.0 Unity- + Unreal-Parität, mit umfassender Validierung
• HelloAR-Beispiele in beiden Bindings, mit expliziten Failover-Demonstrationen
• Verbesserte Unity-Beispiel-Interaktionen mit Multi-Objekt-Unterstützung und interaktiven Tutorials
• Verbesserte Unreal-API-Dokumentation mit umfassenden Nutzungsbeispielen
• Agent-Queue-Seeder-Workflow ins SDK-Repo portiert
• CI/CD-Pipeline für SDK-v0.2-Paketveröffentlichung mit semantischer Versionierung und Release-Automatisierung
• SDK-v0.2-Dokumentation und Schnellstart mit Repository-Homepage- und Wiki-Integration
• Epic #42: SDK- & Runtime-Paritätstest-Infrastruktur abgeschlossen

Die Epic-#42-Arbeit ist die Schlagzeile. Es ist eine Testsuite, die beide Bindings gegen dieselben kanonischen Szenarien ausübt und bestätigt, dass sie sich gleich verhalten. Unity-HelloAR und Unreal-HelloAR laden jeweils ein Modell, verankern es an einem Marker, rendern es und melden Telemetrie. Der Paritätstest bestätigt, dass die von den beiden Bindings gemeldete Telemetrie innerhalb der Toleranz liegt und dasselbe Modell in beiden korrekt lädt. Wenn eine Runtime-Änderung jemals ein Binding bricht, ohne das andere zu brechen, fängt der Paritätstest das ab.

Warum Paritätstests in dieser Phase wichtig sind

Das Raku-SDK liefert noch nicht aus. Es gibt keine öffentliche Veröffentlichung. Wir sind Monate davon entfernt, dass jemand außerhalb des Teams Code dagegen schreibt. Warum sich also jetzt um Parität kümmern?

Weil Paritätstests, die am Anfang eines Projekts gebaut werden, tausendmal weniger kosten als Paritätstests, die nachträglich in ein bereits ausgeliefertes Projekt eingebaut werden. Jede neue C-API, die die Runtime hinzufügt, wird ab Tag eins durch beide Bindings ausgeübt. Jeder PR, der die öffentliche Oberfläche berührt, muss entweder zeigen, dass der Paritätstest immer noch besteht, oder erklären, warum nicht. Die Kosten sind ein paar Minuten pro PR. Die Ersparnis sind Monate an Triage nachgelagert, wenn ein Partner ein Problem meldet, das nur auf Unreal reproduziert, und das Team herausfinden muss, warum.

Der andere Grund ist, dass Paritätstests architektonische Probleme aufdecken. Wenn ein Feature leicht in Unity und schwer in Unreal zu exponieren ist, liegt das Problem meist nicht in den Bindings. Es liegt in der C-API der Runtime. Die Asymmetrie ist ein Signal. Dieses Wochenende deckten die Paritätstests zwei solche Asymmetrien auf, und die Lösung war in beiden Fällen, die API-Oberfläche der Runtime zu ändern, statt die Asymmetrie in einem der Bindings zu umschiffen.

Wie der Zwei-Ströme-Workflow funktioniert

Das Muster, auf das ich mich für Multi-Repo-Entwicklung mit Agenten festgelegt habe:

Eine Agenten-Warteschlange pro Repo. Die Runtime hat ihre eigene Issue-Warteschlange, das SDK hat seine eigene, die Docs haben ihre eigene. Jeder Agent arbeitet innerhalb seines Repos. Kein einzelner Agent versucht, die Naht zwischen zwei Repos in einem PR zu überspannen.

Repo-übergreifende Koordination auf Issue-Ebene. Wenn ein Feature Änderungen in beiden Repos erfordert, werden zwei gekoppelte Issues gleichzeitig eingereicht, mit Querverweisen. Der Runtime-PR landet zuerst. Der SDK-PR wird zurückgehalten, bis der Runtime-PR gemerged ist. Dann wird der SDK-PR gegen den neuen Runtime-Build aktualisiert, erneut getestet und innerhalb weniger Stunden gemerged.

Ein kanonisches Beispielset in jedem Binding. Unity-HelloAR und Unreal-HelloAR sind die kanonischen Testfahrzeuge. Jede C-API-Änderung muss in beiden ausgeübt werden. Die Beispiele sind keine Nachträge. Sie sind Teil der öffentlichen Oberfläche.

Paritätstests als CI-Gate. Die Paritätstest-Infrastruktur, die dieses Wochenende als Epic #42 gelandet ist, läuft jetzt bei jedem PR, der eines der beiden Repos berührt. Wenn eine Runtime-Änderung nicht beide Bindings ausübt, wird der PR vom Mergen blockiert, bis der Paritätstest zeigt, dass die Änderung auf beiden Seiten funktioniert.

Was das für Bauende ermöglicht

Wenn du ein Unity-Entwickler bist und darüber nachdenkst, irgendwann auf Raku zu bauen, wird das Binding gemeinsam mit der Runtime entwickelt, nicht ihr hinterhergejagt. Die Unity-API wird nicht hinterherhinken. Die Beispiele werden heute funktionieren, und sie werden in Version 1.0 funktionieren.

Wenn du ein Unreal-Entwickler bist, gilt dasselbe. Das Unreal-Binding hat dieselbe Priorität wie das Unity-Binding. Die Paritätstests beweisen es.

Wenn du entscheidest, mit welchem Binding du anfängst, ist die Antwort: was auch immer zu den bestehenden Fähigkeiten deines Teams passt. Die Paritätstests sind das, was mir erlaubt zu versprechen, dass die Binding-Wahl dich später nicht von Features aussperren wird.

Wenn du ein Partner bist, der darüber nachdenkt, wie diese Engine in deinen Stack integriert, wird die Oberfläche C-API plus Unity-Binding plus Unreal-Binding plus irgendwann noch ein paar mehr sein (Godot ist auf der Roadmap, web-nativ ist auf der Roadmap). Jedes neue Binding muss seine eigenen Paritätstests gegen das kanonische Set landen, bevor es ausliefert. Die Disziplin ist eingebaut.

Ehrlich darüber, was noch rau ist

Die Paritätstests decken die Grundlagen ab. Markerbasierte Verankerung funktioniert in beiden Bindings. HelloAR lädt und rendert in beiden. Telemetrie meldet korrekt in beiden. Die schwierigeren Paritätsfragen - vollständiges Handtracking, Sprach-Pipeline, Multiplayer-Pose-Sync - sind noch nicht paritätsgetestet, weil die Runtime-Seite noch nicht fertig ist. Sie werden unter demselben Gate kommen, wenn sie es sind.

Die CI-Pipeline für die SDK-v0.2-Veröffentlichung steht, aber das tatsächlich veröffentlichte Paket ist noch nicht stabil genug, um zur Integration zu empfehlen. Behandle das SDK bis in den Oktober hinein als in Entwicklung. Bis November werden die Paritätstests tief genug sein, dass die Empfehlung anders ausfällt.

Was ich mir von diesem Wochenende merken möchte

Zwei Dinge.

Multi-Repo-Parität ist eine Disziplin, kein Feature. Das Wochenende, an dem das SDK zur Runtime aufholte, ist ein Wochenende ohne glänzendes neues Feature in der Runtime. Nichts Vorführbares ist passiert. Was passiert ist, ist, dass das SDK nicht mehr hinterherhinkt. Das ist die Art von Arbeit, die, vernachlässigt, ein Multi-Repo-Projekt tötet. Ich möchte das aufschreiben, damit ich es nicht vergesse, wenn das nächste große Runtime-Feature landet.

Die Agenten-Warteschlange skaliert nach Repo. Eine Warteschlange über beide Repos im selben Workflow laufen zu lassen, produzierte eine frühe Version des Merge-Konflikt-Breis, den ich letztes Wochenende auf Runtime-Ebene beschrieben habe. Die Warteschlangen nach Repo zu trennen, eliminierte fast alles davon. Die Agenten hören auf, sich gegenseitig auf die Füße zu treten, wenn ihre Problemräume ordentlich zerlegt sind.

Samstagabend, SDK und Runtime sind auf Parität. Großes Wochenende. Die richtige Art Wochenende.