Da ist etwas, das ich an dem Thema „Abwärtskompatibilität“ bemerkt habe: Es wird oft übersehen, wenn ein System noch neu ist.
In den frühen Phasen sind Veränderungen leicht. Fast niemand ist zu diesem Zeitpunkt tief von vorherigen Versionen abhängig, sodass Modifikationen selten echte Störungen verursachen. Doch irgendwann kommt der Punkt, an dem genug Organisationen das System integriert haben, sodass jede Änderung am Policy-Schema oder an der Attestationsstruktur eine Entscheidung mit hohen Risiken wird. Das Problem ist, dass die meisten Projekte nicht im Voraus ankündigen, wie sie damit umgehen werden. Sie kümmern sich erst darum, wenn sie dazu gezwungen werden. Dann behalten sie entweder die alte Kompatibilität bei und nehmen technische Schulden in Kauf, oder sie zwingen alle dazu, komplett von vorn neu aufzubauen.
Das Newton-Protokoll befindet sich noch in dieser leicht veränderbaren Phase. Die Anzahl der realen Integrationen ist noch nicht groß genug, damit eine architektonische Änderung weitreichende Folgen nach sich zieht. Das ist die beste Zeit, sich öffentlich zu Prinzipien der Abwärtskompatibilität zu bekennen – bevor der Druck durch die wachsende Akzeptanz diese Entscheidungen in Eile erzwingt.
Natürlich verdient diese Idee Kritik. Ein junges Projekt zu bitten, detaillierte Zusagen zur Abwärtskompatibilität zu machen, könnte zu früh sein. In dieser Phase braucht die Architektur noch Flexibilität, um sich schnell anhand von Marktfeedback anpassen zu können. Zu starre Zusagen könnten dem Team selbst die Hände binden. Aber zumindest einige allgemeine Grundsätze, zum Beispiel das Ausmaß an Vorankündigung für Breaking Changes, könnten früh angekündigt werden, ohne die Entwicklungsfreiheit einzuschränken. $NEWT ist derzeit nicht an solche Zusagen gebunden.
Leicht änderbar zu sein heißt nicht, dass es immer leicht bleiben wird.
Ich beobachte, ob Newton Prinzipien zum Umgang mit Breaking Changes ankündigt, bevor die Zahl der Integrationen diese Frage dringend macht.
