Versionierung und Kompatibilität
Plattform, MDT und Bridge haben getrennte Versionsstände. Eine neue Website-Version bestätigt deshalb nicht automatisch die Kompatibilität eines Spielserver-Pakets.
#Vor einem Update
- Plattform-, MDT-, Bridge-, Framework- und Adapterversion erfassen.
- API-Vertragsversion und tatsächlich registrierte Endpunkte prüfen.
- Migrationen und betroffene Rechte im Changelog lesen.
- Testumgebung auf denselben kombinierten Stand bringen und Signatur, Identität, Dienst, Ticket und gegebenenfalls Druck prüfen.
- Erst nach positiver Abnahme ein unveränderliches Artefakt freigeben.
#Vertragsstände
| Vertrag | Aussage |
|---|---|
| Connector v1 | Dokumentierte HMAC-Köpfe und Fachendpunkte |
| Ticket-Ergänzung ab MDT 0.7.8 | Charakterbezug, Spielwelt und Gerätebindung |
| Connector v1.1 | Jobsynchronisierung, Fahrzeuge, Outbox und Platzierungsabruf geplant |
| Plattform Game API | Eigenständige Bearer-API; nicht Connector v1 |
Interne Kopf- und Schemanamen bleiben für Kompatibilität unverändert. Anzeigen heißen LexoNET. Ein dokumentierter API-Endpunkt ist erst verwendbar, wenn er in der Zielversion registriert, aktiviert und berechtigt ist.
#Änderungen ankündigen
Sachlich festhalten: betroffene Version, bisheriges Verhalten, neues Verhalten, erforderliche Konfiguration, Migration, Tests und Rückfallgrenze. Für geplante Endpunkte keine Verfügbarkeit oder Auslaufdaten versprechen. Ein allgemeines öffentliches Abkündigungsfenster ist in den geprüften Quellen nicht festgelegt.
#Typische Fehler
- Dokumentationsversion mit Softwareversion gleichsetzen: getrennt erfassen.
- v1.1-Endpunkte vorsorglich abfragen: noch nicht verfügbar.
- Geheimnisrotation mit Release-Rollback verwechseln: Rotation besitzt einen eigenen Widerrufsablauf.
#Wer darf das?
Entwickler führen Kompatibilitätsprüfungen aus. Release- und Systemleitung entscheiden über Versionen und produktive Freigaben.
Unklare Stellen oder fehlende Schritte meldest du im LexoNET-Discord oder als Ticket im Kundenbereich.