わかりました、でもそれだとさらに理解できなくなりました 
結局、@david の最新のコメントによると、あまり重要ではないので、まとめます。
提案されているモデルは、月次リリースと 2 つの esr バージョンです。たとえば 2026 年の場合:
したがって、2026 年 10 月で、.2 と .8 が esr バージョンであると仮定すると、4 つのサポート対象バージョンが存在することになります。
そして私の考えはこうでした。四半期ごとのバージョンにする方が簡単ではないか、つまり 2026 年の場合:
そして、現在リリースされているバージョンと前のリリースのみがサポートされると仮定すると、2026 年 10 月には 2 つになります。
そして、このすべての理由は、開発者とユーザーの両方にとってより簡単になるのではないかということでした。しかし、前述のように、@david はより頻繁でないリリースは選択肢ではないことを明確にしました。
了解しました。それは大まかに私が予想していた方法です。実際、この場合、少なくとも中期的にツールのサポートが少しあると良いでしょう。
私がそれを概念化する方法は次のとおりです。あなたは特定のリリースチャネル（latest、release、esr）にいて、通常は次のリリースに比較的すぐに移行します。そのため、新しいリリースが利用可能になったときにメッセージや通知を受け取り、それに切り替えるための単一のコマンドがあると便利です。また、新しいリリースの採用を遅らせた場合、現在使用しているリリースが廃止/サポートされなくなったときにリマインダーを受け取ることもできます。それぞれのツールでリリースチャネルをすばやく切り替えることができる場合、さらに良いでしょう 
しかし、それが現時点で最優先事項ではないことは理解しており、テスト済み/最新版に留まることをお勧めします。
なるほど。私の仕事の文脈では、顧客に機能を提供することは「速い」と見なされます 
また、上記で述べたように、四半期ごとのスケジュールに移行することで、メンテナンスするブランチが少なくなるため、あなたの（そしてプラグイン/テーマ開発者の）生活が楽になるのではないかと考えました。もしそうでないなら、それはあなたにとって実際には意味がないのでしょう
この年ベースのバージョン管理スキームには何のメリットも見出せません。提案されているものには従わず、SemVer 準拠のバージョン番号を使用してください。
SemVer自体は、大規模なアプリケーション向けには設計されていません。ソフトウェアに消費されるライブラリを対象としており、特にバージョン番号のロジックはパッケージのAPIを中心に構築されていると理解しています。
ただし、SemVerをAPIに適用することは可能です。Discourseが公開するAPIに関するより強力な保証を持つことは、確かに議論する価値のあることですが、それは今回の議論とは別だと思います。
さて、SemVerに準拠する必要があるとは言っていないことは理解しています。SemVerで指定された番号付けシステムに準拠した「数値」を使用し続けるべきだと言っただけです。
- 通常のバージョン番号は、X.Y.Z の形式でなければならず、X、Y、Z は非負の整数で、先頭にゼロを含んではいけません。X はメジャーバージョン、Y はマイナーバージョン、Z はパッチバージョンです。各要素は数値的に増加しなければなりません。例：1.9.0 → 1.10.0 → 1.11.0。
このルートに進む場合、唯一壊れる可能性があるのは「先頭にゼロを含まない」という提案だと思います。
それ以外は、SemVerライブラリであれば、提案しているバージョン番号を解析し、適切に並べ替えることができると思います。
それらはさておき、SemVerの番号付けシステムに準拠することにどのような価値があると考えているのか、もっと教えていただけますか？
OPは、私の理解が正しければ、先頭のゼロを使用していないと言っています。
バージョンによるソートのために先頭のゼロを使用するという、説得力のある理由も提案されていると思います。先頭のゼロは現在の計画ですか？（私はまだシリアルバージョンよりも月バージョンの方が好きです）。
SemVerのポイントは、バージョン番号が有用な情報を伝えるべきであるということです。あなたの提案するスキームで伝えられる唯一の情報は、太陽の周りの地球の軌道です。その情報は、ソフトウェアの消費者にとってあまり有用ではありません。
もし何らかの理由でリリース日を知りたいのであれば、リリースを見て完全な日付を確認するでしょう。
そうではありません。ポイントは、リリースの性質をユーザーに伝えることです。
リリースがパッチバージョンの引き上げである場合、これは変更セットにソフトウェアのユーザーのワークフローに影響を与えることが予想されるものは含まれていないことを伝えています。
リリースがマイナーバージョンの引き上げである場合、これは変更セットに新しいユーザー向けコンポーネントの追加が含まれているが、ソフトウェアのユーザーの既存のワークフローを壊すものはないことを伝えています。
リリースがメジャーバージョンの引き上げである場合、これは変更セットにソフトウェアのユーザーの既存のワークフローを壊す可能性のある変更が含まれていることを伝えています。
どのバージョンコンポーネントを引き上げるかの決定は、単一のユーザーインターフェイスを持つソフトウェア製品ではより明確ですが、Discourseのような、さまざまなレベルのインターフェイスやさまざまな種類の消費者（プラグイン開発者、API消費者、フォーラムスタッフ、エンドユーザーなど）がいるソフトウェア製品でも原則は同じです。
このソフトウェアプロジェクトでは、どのコンポーネントを引き上げるかの選択が少し主観的になったとしても、あなたの提案の場合のように、単なる任意の番号ではなく、バージョン番号に意味が生まれます。
数投稿前に提案しました。
semverとは対照的に、提案されたバージョン番号付けスキームは、バージョンがまだサポートされているかどうか（Ubuntuのように）をすぐに明確にします。これも地球の太陽周回軌道に依存するため、理にかなっています。
これは明らかにパッケージやライブラリを対象としています。あらゆる Discourseリリースには、ソフトウェアのユーザーの既存のワークフローを壊す可能性のある変更が含まれています。セキュリティパッチでさえ、そのようなことをしたのを見たことがあります。semverは複雑なアプリケーションには使用できません。
はい、実際そうです。こちらをご覧ください。
公開APIを特定したら、バージョン番号への特定のインクリメントで変更を伝えます。
失われがちな点を強調するために、Discourseはここで素晴らしい仕事をしていると思います。1つの改善点は、そのアップグレードサイクル内で変更や潜在的な破損を説明する、すでに記述したトピックを少なくとも強調することです。たとえば、3.5リリースでは、リリースノートを開き、ブログへのリンクをクリックし、Discourseコアにプラグインをバンドルすることに関するリンクを偶然クリックして、設定ファイル内にそれらのプラグインを残すことがアップグレードに影響を与える可能性があるという詳細を把握する必要がありました。
ESRリリースについては、既存のトピックへのリンクのセットであっても、ESRアップグレードを実行する前にレビューする必要があるページ/トピックにそのようなメモを抽出すると素晴らしいでしょう。
ただし、これはこのスレッドの範囲を超える可能性があります。バージョン変更に関する私のフィードバックは、それを歓迎し、ここでの透明性に感謝しているということです。これは、より多くのセルフホスティングオプションを提供しながら、物事を単純化する素晴らしい改善になると思います。
ありがとうございます！
はい、そしてそれはとても良いアイデアなので、opがそれを反映するように編集されるべきだと思います！
先頭のゼロや、より明確に月との同期を目指すかどうかを検討中です。この件に取り組んでいるグループが決定に至り次第、@david がアップデートを共有します。
それは、フォーラムのメンテナーが新しいリリースを評価する上で重要な情報ではありません。
いいえ、本当に。あなたは「API」が実際にはインターフェースを意味するだけであることを理解することを拒否することによって、SemVerの実際のポイントを逃しています。SemVerの精神をあらゆる種類のソフトウェアのバージョン管理に使用できない理由は全くありません。
この点については、合意できないということで @per1234 さん。\n\nsemver の GitHub リポジトリでの関連する議論と、メンテナーの1人からの回答を以下に示します。\n\n> Semver は「エンドユーザーアプリ」にはあまり役立たず、プロジェクトの依存関係として使用するライブラリにより役立ちます。
ライブラリであれ、大規模なアプリケーションであれ、セマンティックバージョニングスキームはうまく機能します。プラットフォームにバンドルされたアプリケーションのコレクションにも使用できますが、ここでは非常に扱いにくくなります。
主な質問は、サポートされている非推奨を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であると提案します。
バージョン文字列はさておき。新しいリリース計画は気に入っています。
はい、特に柔軟なテーマシステムにおいては、現状はまさにそうなっています。
ですから、ここで的確に指摘されていると思います。
これはまた、現在のバージョン番号の「メジャー」部分がほとんど何も伝えていないことも意味します。
ですから、「何かを伝えるために、そこに年を使うのはどうか」と感じました。
この議論は良くないですね。開発チームが新しいバージョン管理システムを採用するという決定が見えますが、それは彼らにとって理にかなっています。そして、Discourseのバージョンがセマンティックバージョニングに従っていたと突然考えるようになった他の人々もいます…実際にはそうではありませんでした。少なくとも1.0以降は常にローリングリリースでした、あるいはそうでしたか？
しかし、議論の両側の主張は欠陥があるようです。
私が認識している主な変更点は、月次ペースを採用することで、Discourseチームが期待を設定し、リリース目標から離れて、定期的なリリースを受け入れることです。
8ヶ月のLTSは「長い」とはあまり聞こえません。NodeJSは非常に速く動いていますが、30ヶ月以上のLTSサポートといくつかの現在のバージョンを同時に維持しています。Ubuntuは長年LTSを維持しています。Discourseは言語でもOSでもないことは理解していますが、新しい機能がかなり速いペースで出荷されることを示唆しているようです。これは別の問題を引き起こします。時々新しい管理設定が導入されるので、すぐに無限のオプションとサイト管理の理解不能な複雑さ、つまりブロートウェアを備えたWordPressの地獄に陥ることになります。その場合、ターゲットを持つ既存のリリースから定期的なリリースにどのように移行するか、そしてどのターゲットをリリースにドロップ（または延期）するかをどのように選択するかを明確にすることが重要になります（これはすでに文書化されているかもしれませんが、私はそれを見逃しました）。
開発ペース/バージョン管理の根拠と、管理者が設定過多と学習曲線の増大に溺れるのを避けるために何を考えているかを共有していただけますか？
この提案によって、意図しているリリース頻度は変更されません。
この新しい提案では、これまでと同様のリリース間隔を維持する予定ですが、主な変更点は以下の通りです。
これを踏まえて、設定が多すぎるという他の質問は、この提案に関連するものだとお考えですか？それとも、別のトピックで議論した方が良い独立した懸念事項でしょうか？
mcwumblyさん、詳しいご説明ありがとうございます！
確かに、これは別の懸念事項です。プラグインを使用して管理画面をカスタマイズすることは、どのようなものになるかについてのテストを行うのに役立ちます。そのようなアプローチに関する進行中の作業はありますか？
具体的にはこれではありませんが、過去1年間で管理画面UIの改善にかなりの投資を行ってきました。これらの点についてさらに詳しく知りたい場合は、新しいトピックを開始して、さらに議論したい問題やアイデアをいくつか提示していただけますか？
これは素晴らしい変更です（特にオーバーラップするESRが気に入っています）
フィードバック：
ライフサイクルグラフを一元化されたページで確認できるようにしたいです。そうすれば、EOLテーブルと合わせて、いつでもサポート対象内およびサポート対象外のものを簡単に確認し、計画を立てることができます（少なくともESRについては）。
ストリームの切り替え：
これは素晴らしいでしょう。しかし、セットアップ中にタグを選択できるだけでも大きな進歩です。あるいは、セットアップドキュメントに手動の手順を含めるだけでも良いでしょう。誰かが安定版/ESRから始めたい場合、現在のところ新しい管理者にはそれがどのようにできるのか明確ではありません。（答えは、./launcherに--skip-rebuildを渡してから、バージョンを編集し、初めてリビルドすることだと思いますが、確信はありません。）そうでなければ、セットアップはすぐに最新バージョンを取得して実行し始め、後戻りするのは問題を引き起こす可能性があります。
（新しい管理者にとっての難しさの例：現在、「discourse stableをインストールする」という検索結果の1番目は、このスレッドに誘導されます。これは別のスレッドにリンクしており、安定版にアップグレードする方法を説明していますが、最初から安定版をインストールする方法は説明していません。）
本日、このRFCの導入に向けたさらなる一歩として、Discourseの最新バージョンがv2025.11.0になりました 