Schon vor zwei Jahren stellte ich mir die Frage, was denn eigentlich die gängige Vorgehensweise der Versionierung von WordPress Plugins ist. Meine Überlegungen finden Sie auf dieser Seite.

Empfehlung von WordPress zum Thema Versionierung

Auf den Codex-Seiten von WordPress habe ich keine Anhaltspunkte für “best practices” und zur Versionierung von WordPress Plugins gefunden. Jedoch wird an einer Stelle in den PHP-Documentation-Standards darauf hingewiesen, dass die Zahl dreistellig sein sollte (x.x.x). Es bleibt somit jedem selbst überlassen, wie er es machen will.

Wie versionieren andere?

Sehr schnell bin ich auf diesen Beitrag bei Stackoverflow gestoßen: Best Practice: Software Versioning. Die als beste Antwort markierte Nachricht empfiehlt zumindest schon mal, dass man mit 1.0 anfangen soll. Außer man sei sich sicher, dass es sich um eine Version handelt, die noch sehr “buggy” sei oder eben noch jede Menge größere Änderungen erwartet. Darüber hinaus muss man jedoch auch nicht jeden einzelnen Commit mit einer neuen Versionsnummer versehen.

Es gibt sogar einen Standard!

Die beste Antwort (für mich) war allerdings ein Link auf die Seite Semantic Versioning 2.0.0. Denn sie beschreibt eigentlich genau das, was ich (gefühlt) schon immer getan habe. Damit ist folgende Struktur gemeint:

MAJOR.MINOR.PATCH

Zu Deutsch: “Haupt-“.”Neben”.Patch.

Das bedeutet:

• Die erste Nummer steht für größere Änderungen wie z.B. inkompatible API-Veränderungen. Also Beispielsweise ein Versionssprung von Windows 7 auf Windows 8.
• Die zweite Nummer steht für alle Änderungen, die neue Funktionen hinzufügen, die aber immer noch Rückwärts-Kompatibel sind.
• Und die dritte (und damit letzte Nummer) steht für die Anzahl der Patches/Updates/Fehlerbehebungen. Wobei ein “Patch” so definiert ist, dass er falsches Verhalten korrigiert.

Das wiederum passt auch gut mit der WordPress-Empfehlung  (dass immer drei Nummern verwendet werden soll) zusammen. Perfekt. Nach so etwas habe ich gesucht, auch wenn sich das so genannte “Semantic Versioning” eher an die Entwicklung von APIs orientiert.