この議論は良くないですね。開発チームが新しいバージョン管理システムを採用するという決定が見えますが、それは彼らにとって理にかなっています。そして、Discourseのバージョンがセマンティックバージョニングに従っていたと突然考えるようになった他の人々もいます…実際にはそうではありませんでした。少なくとも1.0以降は常にローリングリリースでした、あるいはそうでしたか？
しかし、議論の両側の主張は欠陥があるようです。
- 「業界標準」：Linuxは安定版に偶数メジャーを、開発版に奇数メジャーを使用しています。
- 「地球が太陽の周りを回る」：イスラム教に改宗すると、バージョンを落とすことになるので問題が発生します。そして、太陽の公転ではなく、月の周期に合わせることになります。ここで、X.Y.Zバージョン管理スキームではなくYYYY.Y.Zバージョン管理スキームを選択することで、支配的な文化を強制したことがわかります。
- マイナーリリースは不明瞭なままです：あなたは「月次リリースを想定する」と述べていますが、機能によっては3週間または7週間になる可能性もあります。その場合、0からYを数えるのが理にかなっています。あるいは、実際に月次リリースを目指しており、その場合、1からMを数える方が理にかなっていますか？
私が認識している主な変更点は、月次ペースを採用することで、Discourseチームが期待を設定し、リリース目標から離れて、定期的なリリースを受け入れることです。
8ヶ月のLTSは「長い」とはあまり聞こえません。NodeJSは非常に速く動いていますが、30ヶ月以上のLTSサポートといくつかの現在のバージョンを同時に維持しています。Ubuntuは長年LTSを維持しています。Discourseは言語でもOSでもないことは理解していますが、新しい機能がかなり速いペースで出荷されることを示唆しているようです。これは別の問題を引き起こします。時々新しい管理設定が導入されるので、すぐに無限のオプションとサイト管理の理解不能な複雑さ、つまりブロートウェアを備えたWordPressの地獄に陥ることになります。その場合、ターゲットを持つ既存のリリースから定期的なリリースにどのように移行するか、そしてどのターゲットをリリースにドロップ（または延期）するかをどのように選択するかを明確にすることが重要になります（これはすでに文書化されているかもしれませんが、私はそれを見逃しました）。
開発ペース/バージョン管理の根拠と、管理者が設定過多と学習曲線の増大に溺れるのを避けるために何を考えているかを共有していただけますか？
