私のDiscourseのインストールが古くなりました（3.2.0.beta4-dev）ので、3.5にアップグレードする必要があります。WP Discourse、WordPress経由でのメンバーシップ情報を使ったログイン、Category Lockdownプラグインといった、変更したくないいくつかのプラグイン/統合をいじってしまい、過去に手動でアップグレードした際に問題が発生したことがあります。
アップグレードの最善の方法は何でしょうか？一度別のバージョンに部分的にアップグレードするようなことをすべきでしょうか？注意すべき点はありますか？
テストフォーラムをデプロイしてください。フォークしたことは一度もありません。
安全を期すなら、新しいサーバーを起動し、rsync を使用して Discourse サイトを別の VPS に移動する（データベースファイルはスキップすることをお勧めします）、そしてバックアップを復元するのが良いでしょう。
おそらく、PostgreSQL 15 アップデートが必要になるはずです。
WP Discourse に関しては問題ないはずです。Discourse Category Lockdown を確認できます。
PG 15 のアップグレード手順に従えば問題なく動作する可能性が高いですが、「ベストプラクティス」について質問されました。
これは、最近のバックアップがあり、そのバックアップの安全なコピーがあることを保証するという良い副作用があります。アップグレードの方法に関わらず、これらのことを行う必要があります。
すべてのプラグインをコメントアウトすることも良い習慣になると思いますが、誰かに確認してもらうのが良いでしょう。
ええ。実際、新しいサーバーを起動してバックアップを復元できることを知っておくことは重要です。最近、私のサーバーの1つのSSDが故障したときに、これを実行する必要がありました。実際に練習しておけばよかったと思ったのですが（結局、明示的に練習していなくても、何百回もプロセスを経験していたので十分で、すべて計画通りに進みました）。
特に、多くのプラグインがコアに移動され、古いものが壊れている可能性があることを考えると、デメリットはありません。すべてが正常に動作するようになったら、不足していると思われるプラグインを復元していくことができます。
ベストプラクティスは？チェックリストをどこかに保管してください。UIにチェックリストを追加できます。
管理 > 更新
テーマに次のCSSを追加してチェックリストを追加できます（../admin/customize/themes/ edit）。もし将来、あなたや誰かが速すぎるアップデートをしようと思ったら：
.admin-contents.update .d-nav-submenu::before {content:“アップデートチェックリスト” : バックアップは完了しましたか？ ; 先月のメタアナウンスメントは読みましたか？ ; 先月の最も重要なバグをメタで確認しましたか？ 必須プラグインの互換性は確認しましたか？ Postgres/Redisの互換性バージョンは確認しましたか？ アップデートの適切なタイミングは確認しましたか？ アップデート失敗時のトラブルシューティング体制は整っていますか？ }
チェックリストは良い考えです。私自身、アップグレードを検討する際には、リリースを待ち、数日待ち、平日を待ち、バグとサポートのカテゴリを読んで、人々がどのような問題を抱えているかを確認します。そして、もし問題があれば、それらが修正されるのを待ちます。
おそらく安定版をご利用ですか？そうでなければ、この戦略は継続的インテグレーションには役立たないでしょう…
いいえ、tests-passed を利用しています。数日遅らせることで、さらにいくつかのコミットがリポジトリに追加される可能性がありますが、同時にいくつかの間違いが修正される可能性もあります。もちろん、ほとんどのコミットは問題ありませんので、良いトレードオフだと思いますが、意見が分かれるところかもしれません。
新しいベータ版の直後に多数のアップグレードが行われるため、テストに合格した後でも、アップグレードの数日後がアップグレードに適した時期です。あるいは、私たちはおそらく同じ欠陥のあるロジックを共有しているのかもしれません！
グラフによる裏付けがない限り、納得できません。
コミットの割合のうち、バグ関連のものを（どうやって定量化するかは不明ですが、コミットに「FIX」が含まれているものを数えるなど）リリース後の5日間と、それ以外の期間の割合を比較して、何かが見られると思います。