ライブラリであれ、大規模なアプリケーションであれ、セマンティックバージョニングスキームはうまく機能します。プラットフォームにバンドルされたアプリケーションのコレクションにも使用できますが、ここでは非常に扱いにくくなります。
主な質問は、サポートされている非推奨を1つのリリースで行い、次のメジャーリリースでのみ削除するというルートを進むかどうかです。非推奨だがサポートされている機能は、かなりの労力を要する可能性があります。永続化されたデータモデルの変更を行う場合、非推奨にすることが不可能になることがよくあります。そうなった場合、非推奨の機能を持つマイナーバージョンすら行うことができず、すぐに次のメジャーバージョンにジャンプします。これは、大規模なアプリケーションが通常問題を抱える部分です。互換性を提供できないため、3.0.0から3.0.1、そして4.0.0にジャンプします。破壊的な変更が頻繁にある場合、semverに固執してもほとんど価値がありません。
とはいえ、開発者にとって破壊的な変更があることをより明確に伝えることができるため、私はその構成をはるかに好みます。YYYY.Nスキームは、開発者としても管理者としても何も教えてくれません。
したがって、質問は、バージョンで何を伝えたいかということです。6回の機能リリース（破壊的である場合とそうでない場合がある）を行い、6回ごとのリリースがパッチでより長くサポートされるようにし、パッチリリースをバージョン管理したくない場合。その場合、X.Yは適切なスキームであり、Y=0はより長くサポートされるものです。Xは単なる番号になります。問題は、Xが年である場合、Yはすぐに月に連想されることです。そのため、新しいより長くサポートされるリリースは1月にリリースされますか？UbuntuのどのバージョンがLTSであるかを常に調べる必要があり、それは私を悩ませます。
では、Discourseが現在のメジャーバージョンを単純に継続したらどうなるでしょうか。次に長くサポートされるバージョンは4.0と呼ばれ、次に機能リリースとして4.1から4.5が登場し、次に最新のより長くサポートされるバージョンである5.0が登場します。
そうすれば、メジャーな問題のためにリリースが遅れるという厄介な瞬間もなくなります。
明示的にパッチをリリースする予定がある場合（ローリングパッチリリースではなく）は、オプションで「パッチ」番号を追加できます。「しかし、x.y.zになり、それはsemverになります。」いいえ、semverのように見えますが、そうではありません。すべての新しい「マイナー」リリースは破壊的である可能性があります。したがって、X.Yをバージョン管理スキームとして、Y=0がLTSであると提案します。
バージョン文字列はさておき。新しいリリース計画は気に入っています。