Changelog – XTend 0.8.0

Diese Seite beschreibt den 0.8.0-Stand der Codebase und seine Migrationen. Die Paketversion allein bestätigt keine Veröffentlichung; den ausgelieferten Stand bestimmen Manifest, Exports und Build-Artefakte.

XTend 0.9.0 – Renderer- und Resume-Verträge

Renderer v2 behandelt Strings in attributes/attrs als Literale, auch bei gleichnamigen Modellschlüsseln; bisherige implizite Attribut-Bindings müssen explizit werden. Eigenständige SSR-Coverage und gemeinsamer initialer Resume-Envelope für Node/Laravel. Legacy-Verträge bleiben mindestens in 0.9/0.10 unterstützt, Entfernung frühestens mit 1.0. Kernel- und MCP-Artefakte werden neu erzeugt; die verpflichtende Nightly-Matrix umfasst Laravel 12/13. Binding-Migration und Regressionstests.

Änderungen in 0.8.0

Bereich	Verhalten und Einstieg
RMT Microkernel	Eine Scheduler-Autorität, sechs kanonische Lanes und abbrechbare, thenable RmtJobHandles. Paint-, Idle- und postTask-Warten blockieren keine bereite Arbeit. Migration
Maraca Shell	execution fastpass und dispatchFastPass() führen Navigation, Fokus und benanntes Close über user-blocking aus, unabhängig von wartenden fachlichen Commands. FastPass
Präsentations-Lifecycle	Automatische Surface-Epochen schützen Hydration, UI-Coprocessor-Antworten und geplante Commits. superseded startet keinen synchronen Rendering-Fallback. Fachliche Transaktionen behalten ihre Reihenfolge. Abort Boundaries
Diagnosebedarf	subscribeEvents() liefert unveränderliche Lifecycle-Ereignisse. subscribe() behält vollständige Snapshots; snapshot() und DEV-API-Abrufe lesen synchron aktuelle Daten. DEV API
Hydrangea JIT	Gemeinsame Compile-/Preview-/Maraca-Pipeline und privater Cache geprüfter Kernel-Artefakte. Für den Docs-Host explizit aktivierbar; legacy bleibt Default. Hydrangea
Node und Laravel	Eigenständige Seitenhosts mit Props, Formularen, Navigation, Layouts, Resume und Streaming. Laravel rendert vorgebaute Artefakte ohne Node im Produktionspfad. Seitenlaufzeit
Page Wire und CSP	Opt-in xtend.page-wire.v1 reduziert wiederholte Seitendaten. Bedingte Ansichten materialisieren nur den aktiven Zweig; vertrauenswürdige Komponentenstyles können den Dokument-Nonce übernehmen. Transport
Referenzanwendung	XTend.store verbindet Maraca, Laravel, einen Gastwarenkorb und einen getrennten DemoPay-Provider. Integration
Fokus und Diagnosekorrekturen	Overlay-Fokusfallen berücksichtigen geslottete und remote eingebundene Controls. Delegierte Handler lesen Queue-Statistiken über die gemeinsame Scheduler-Instanz. A11y
Docs Shell	Nach einem Sprachwechsel verwenden Suche und Navigation denselben aktualisierten Locale-Service. Der gemeinsame FastPass-Validator bleibt mit dem älteren Docs-Bridge-Host kompatibel. DEV Surface
Tooling und Nightly	Ein gemeinsamer Testkatalog, geprüfte Runner-Fähigkeiten und an den Run gebundene Artefakte halten lokale und CI-Evidence nachvollziehbar. Release-Verifikation

Migration und Defaults

0.8.0 ist ein Breaking Release innerhalb der Pre-1.0-Policy. Neue Kernel-Aufträge verwenden user-blocking, visible, transition, idle, background oder diagnostics. inline und runInline umgehen die Queue nicht mehr. Product Surface und Prewarm sind explizite Opt-ins; ESM-Importe booten keine Runtime. Fabric liefert Work-Intents und Backpressure und besitzt keine zweite Scheduler-Queue.

FastPass ist ebenfalls Opt-in. Modell-Reducer, Services, Fetches, Streams und beliebige Custom-Effekte bleiben fachliche Commands. Eine abgeschlossene FastPass-Action bestätigt den Shell-Intent, nicht das Laden von Inhalten oder das Ende einer Animation. Lange synchrone Arbeit muss weiterhin kooperativ aufgeteilt werden.

Die erweiterte Plan-Runtime verwendet xtend.maraca.plan-runtime.v3, der Presentation-Adapter xtend.rmt.presentation-effect-adapter.v2. Bestehende Methoden bleiben erhalten; Verbraucher mit Literal-Prüfungen müssen die neue Schema-Major-ID akzeptieren. xtend-maraca/fastpass.schema.json ergänzt den Authoring-Vertrag, ohne das veröffentlichte RMT-v2-Dokumentschema umzuschreiben.

Nach einem Upgrade Maraca-Bundles und Seitenmanifeste mit derselben Framework-Version neu bauen. Rebuilds aktualisieren Runtime-, Asset- und Versionsfingerprints gemeinsam. Aktuelle Paketvoraussetzung ist Node >=24; hostbezogene Kompatibilitäts-Smokes sind keine allgemeine Freigabe älterer Node-Versionen.

Versionsstand ermitteln

Lies die Version nicht aus einem generierten Banner oder Screenshot. Ermittle sie direkt aus dem Package:

node -p "require('./package.json').version"

Vergleiche anschließend package.json mit den tatsächlich installierten Dateien. api.d.ts, components/manifest.json und die Deklarationen unter components/*.d.ts zeigen, welche öffentliche Oberfläche zu diesem Stand gehört.

Änderungen bewerten

• Additiv: Ein neuer Export, ein optionales Attribut oder ein neues versioniertes Schema erweitert die Oberfläche, ohne bestehende Aufrufe zu brechen.
• Verhaltensänderung: Defaults, Scheduling, Hydration oder Fehlerstatus ändern sich. Solche Änderungen brauchen ein ausführbares Beispiel und einen aktualisierten Gate-Report.
• Migration: Ein Name, ein Vertrag oder ein unterstützter Pfad wird ersetzt. Der alte Pfad bleibt mindestens für den dokumentierten Übergang erhalten oder liefert eine eindeutige Diagnose.
• Security Fix: Import-, Integrity-, CSP- oder Trust-Regeln werden verschärft. Ein solcher Fix darf nicht durch einen stillen Kompatibilitätsfallback umgangen werden.

Was ein Release belegen muss

Ein Release ist mehr als eine Versionsnummer. Die Export-Lock-Prüfung muss zu den TypeScript-Deklarationen passen, der Pack-Dry-Run darf keine internen Artefakte veröffentlichen und die relevanten Browser- sowie Runtime-Gates müssen grün sein. Release Verification beschreibt die Reihenfolge und die Bedeutung der Reports.

Upgrade-Pfad

Prüfe vor dem Upgrade zuerst die betroffenen öffentlichen Symbole. Bei RMT vNext helfen die Migration Notes, für Komponenten die Long-Tail Migration und für XTensions der Coexistence Guide. Passe Source, Fixture und Tests gemeinsam an, statt nur einen kompilierten Output zu ersetzen.