Richtlinie zur Rückwärtskompatibilität #

Diese Seite richtet sich an Ingenieure, die Exponential oder eine Erweiterung ändern, und an jene, die Upgrades planen und wissen müssen, was brechen kann. Sie fasst Kompatibilität, Releases und Bereitstellung zusammen.

Inhalt #

1. Was als Bruch zählt
2. Die Regeln
3. Abkündigung
4. Bekannte Ausnahmen
5. Für die aktualisierende Seite

Was als Bruch zählt #

Eine Änderung bricht die Kompatibilität, wenn eine Installation oder Erweiterung, die vorher funktionierte, eine Handlung braucht, um weiter zu funktionieren, oder sich ungefragt anders verhält:

Die Regeln #

• Jeder Bruch hat Upgrade-Hinweise in doc/eng-us/bc/<series>/, beginnend mit der Tabelle In short (Changelogs und Upgrade-Hinweise).
• Neues Verhalten ist optional; Fehlerkorrekturen müssen es nicht sein. Eine Funktion kommt ausgeschaltet oder mit einem Standard, der das alte Ergebnis behält.
• Neue Einstellungen haben einen sicheren Standard in der mitgelieferten Datei, einen Kommentar, einen Abschnitt auf der Funktionsseite und eine Zeile im Changelog.
• Bezeichner werden nicht umbenannt. Klassen, Tabellen, Einstellungen und Pfade eZ* und ezp* bleiben; die Umbenennung des Produkts hat nur Text geändert (Das Produkt heißt Exponential).
• Verschobener Code behält seinen Einstiegspunkt. Als Views, Skripte und Cronjob-Teile in 6.0.15 zu Klassen wurden, behielt jede Datei ihren Pfad als einzeiligen Aufruf.

Abkündigung #

• Eine ersetzte API bleibt verfügbar und wird mit @deprecated und ihrem Ersatz gekennzeichnet; einige schreiben bei Verwendung einen Hinweis im strikten Modus über eZDebug::writeStrict().
• Ein umbenannter Befehl behält seinen alten Namen als abgekündigten Alias, der weiter funktioniert (Forks der Plattformpakete und Umbenennungen von Befehlen).
• Eine Entfernung wird im Abschnitt Removed des Changelogs und in einem Upgrade-Hinweis angekündigt.
• Aus der alten Codebasis geerbte abgekündigte APIs haben kein Entfernungsdatum; für die Linie 6.0 ist keines angekündigt.

Bekannte Ausnahmen #

• Sicherheitsstandards wurden im September und Oktober 2026 ohne Opt-in geändert: Sicherheits-Header, Session-Cookies mit HttpOnly und SameSite, eine strengere Upload-Prüfung, neue Zugriffsanforderungen für einige entfernte Dienste. Sicherheitskorrekturen werden wie Fehlerkorrekturen behandelt: standardmäßig an, dokumentiert mit dem Weg, sie bewusst rückgängig zu machen.
• Konten ohne Zeile in ezuser_setting können sich seit August 2026 nicht anmelden, und Override-Blöcke folgen seit Juli 2026 Priority (Verhaltensänderungen von Juli und August 2026).

Für die aktualisierende Seite #

• Lesen Sie die Checkliste jedes Zeitraums, den Sie durchlaufen, der Reihe nach.
• Durchsuchen Sie Ihre Erweiterungen nach überschriebenen Kernel-Klassen und kopierten Kernel-Templates: Sie erhalten keine Korrekturen und können still brechen.
• ./console exp:checkclasses meldet Klassen, die PHP nicht laden will; die Upgrade-Prüfung vergleicht Dateien und Tabellen mit dem Release.
• Testen Sie mit Ihren eigenen Inhalten und Erweiterungen vor dem Produktions-Upgrade (Eine Änderung bereitstellen).

Verwandte Seiten #

• Aktualisieren
• Die Upgrade-Checkliste für Erweiterungen
• Release- und Upgrade-Planung
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.