Prüfung der API-Versionen vor der Installation überdenken

Ich fürchte, hier liegt ein Missverständnis hinsichtlich des Konzeptes hinter den API-Versionen vor.

Anders als die bisherige Herangehensweise, bei dem der Autor bei jeder neuen Version prüfen muss, ob das Plugin weiterhin lauffähig ist, drehen API-Versionen diese Prüfung um. Die API-Version ist ein Versprechen, dass ein Paket für API-Version X lauffähig ist, selbst wenn andere API-Versionen unterstützt werden. Das Beispiel trifft daher nicht zu, da ein WSC 5.2 die API-Versionen 2017, 2018 und 2019 offiziell unterstützt. Es handelt sich bei der Angabe somit streng genommen um eine API-Kompatibilität.

Dieses Vorgehen hat für uns den Vorteil, dass wir zielgerichtet deprecated Funktionen entfernen können ohne pauschal mit der Kompatibilität aller Plugins zu brechen. Gleichzeitig vermeiden wir damit das lästige excludedpackage auf die jeweils nächste Funktion.

Als Entwickler gibt man alle API-Versionen an, mit denen das Plugin uneingeschränkt lauffähig ist, der Core prüft dann, ob es eine Überschneidung mit den unterstützen Versionen gibt.

Fürs erste werden wir bei den nahezu (*) vollständig abwärtskompatiblen Version bleiben, daher ergibt sich das Problem bis dahin nicht. Es geht vor allem darum, dass System der API-Versionen produktiv zu nutzen und ggf. weiter zu verfeinern, wenn wir dies als notwendig erachten.

Dazu kommt noch, dass wir aktuell an einer Änderung arbeiten, mit der die Nutzung von als "deprecated" markierter Code auch als solcher deutlich gemacht wird. Es gibt immer wieder Entwickler, die keine brauchbare IDE einsetzen und somit nur "händisch" diese Stellen identifizieren können. Generell gilt, dass bei der ältestesten angegebenen API-Kompatibilität kein Code verwendet werden sollte, der zu diesem Zeitpunkt schon deprecated war.

Wir haben uns noch nicht endgültig dazu entschieden, wie wir zukünftig mit umfangreichen Änderungen mit dem Bruch der Abwärtskompatibilität umgehen. Wahrscheinlich läuft es auf ein Verwerfen der Kompatibilität mit allen älteren Versionen hinaus, letztlich ist das System auch für diesen Fall gerüstet - daher auch die Unterteilung in "legacy API versions" im Core.

(*) Die Kompatibilität wird je nach Fall unterschiedlich gewährleistet, dabei kommen Lösungen in dieser Reihenfolge zum Tragen:

1. Die neue Funktion ist vollständig über die alte API verfügbar, Calls werden transparent auf die neue API gemapped.
2. Die alte Funktion kann nicht auf die neue API übertragen werden, das neue System wird parallel hochgezogen, wobei das alte System vollständig erhalten bleibt.
3. Eine Kompatibilität kann nicht erreicht werden und die alte API stellt ein unüberwindbares Hindernis dar. In so einem Fall wird die API so verändert, dass Aufrufe auf die alte API ausdrücklich ohne Fehler bleiben, aber keine Auswirkung mehr haben. Ein Beispiel ist das Kommentar-System, das auf Grund des Wechsels auf HTML/WYSIWYG bei altem Code das Anlegen neuer Kommentare verweigerte.

Der Fall (3.) ist das extremste Szenario und wird von uns so weit es geht vermieden, ggf. werden dadurch aber Änderungen auf eine zukünftige Version aufgeschoben. Als Vorlage dienen uns dabei alte Versionen unserer Apps, um so eine grundsätzliche API-Kompatibilität zu gewährleisten. Dabei gilt, dass der Wegfall von nicht-essentiellen Funktionen im Zweifel hingenommen wird, wenn dies der einzige Weg ist, um Fehler zu vermeiden. Es ist und bleibt eine stetige Gradwanderung zwischen der Unterstützung von Apps und Plugins für ältere Versionen auf der einen Seite, und der kontinuierlichen Weiterentwicklung und Verbesserung des Gesamtpaketes auf der anderen Seite.