Es spielt keine Rolle, ob es sich um eine Bibliothek oder eine größere Anwendung handelt. Ein semantisches Versionierungsschema funktioniert auch für große Anwendungen perfekt. Es kann sogar für eine Sammlung von Anwendungen verwendet werden, die zu einer Plattform gebündelt sind, aber hier wird es ziemlich schwierig.
Die Hauptfrage ist, ob Sie den Weg der unterstützten Deprecation in einer Version gehen und diese erst in der nächsten Hauptversion entfernen. Funktionalität, die als veraltet markiert, aber weiterhin unterstützt wird, kann erheblichen Aufwand bedeuten. Wenn Sie Änderungen an Ihrem persistenten Datenmodell vornehmen, kann die Deprecation oft unmöglich werden. Wenn das passiert, können Sie nicht einmal eine Nebenversion mit veralteter Funktionalität durchführen und springen sofort zur nächsten Hauptversion. Hier haben große Anwendungen normalerweise Probleme. Sie gehen von 3.0.0 zu 3.0.1 zu 4.0.0, weil Sie keine Abwärtskompatibilität gewährleisten können. Wenn Sie häufig brüchige Änderungen haben, bietet Semver wenig Mehrwert.
Davon abgesehen. Ich bevorzuge diese Konstruktion, da sie Entwicklern klarer kommuniziert, dass es brüchige Änderungen geben wird. Das YYYY.N-Schema sagt mir als Entwickler nichts und als Administrator auch nichts.
Die Frage ist also, was möchten Sie mit der Version kommunizieren? Wenn Sie 6 Feature-Releases durchführen möchten (die brüchig sein können oder nicht), und jede 6. Version länger unterstützt wird mit Patches; und Sie möchten Patch-Releases nicht versionieren. Dann ist X.Y ein geeignetes Schema, bei dem Y=0 die länger unterstützte ist. X wäre einfach eine Zahl. Das Problem ist, wenn X das Jahr ist, wird Y schnell mit einem Monat assoziiert. Neuere, länger unterstützte Releases werden also im Januar veröffentlicht? Ich muss immer nachschauen, welche Ubuntu-Version eine LTS ist, was mich ärgert.
Was wäre also, wenn Discourse einfach mit der aktuellen Hauptversion weitermacht? Die nächste länger unterstützte Version heißt 4.0; und dann erhalten wir 4.1 bis 4.5 als Feature-Releases; gefolgt von 5.0, der neuesten länger unterstützten Version.
Dann haben Sie auch nicht diesen unangenehmen Moment, in dem eine Veröffentlichung aufgrund eines größeren Problems verzögert wird.
Sie könnten optional eine “Patch”-Nummer hinzufügen, wenn Sie explizit Patches veröffentlichen möchten (anstatt rollierende Patch-Releases zu haben). “Aber dann haben Sie x.y.z, was Semver ist”. Nun, nein, es sieht aus wie Semver, ist es aber nicht. Jede neue “Neben”-Version kann brüchig sein. Daher schlage ich vor, sich einfach an das X.Y-Versionsschema zu halten, wobei Y=0 → LTS ist.
Abgesehen von der Versionszeichenfolge. Ich mag den neuen Release-Plan.