私は独自のCMSを開発しました-それが最高であるとか、それどころか良いとは言いません。そのようなシステムを作成することで生じる可能性のある問題に直面したかっただけです。
現在、CMS用の合理的なバージョン管理システムの設計に問題があります。
私が今持っているもの：
- プロジェクトはGitHubでホストされています（実際にはまだ）、
- 2つのブランチがあります：
- 現在の変更に対応する
- 開発からの安定した変更のためのメイン
私の最初のアイデアは、GitHub APIを使用して更新システムを作成することでした-ユーザーは、プロジェクトのページでローカルの最新のコミットshaとshaを比較しています-最新のダウンロードファイルではない場合。このソリューションには1つの大きな欠点がありました。APIのリクエスト制限です。1分あたりのリクエストが多すぎるため、1人のユーザーが「更新サーバー」全体をシャットダウンできます。
これの代わりに、「GitHub Pages」を使用して、プロジェクトページを保存し、自分でローカルに生成された変更セットを更新します（追加情報を含むJSON形式の変更されたgit diff出力）。このアイデアでは、コミットを使用して更新ステータスをチェックするのではなく、バージョン番号をチェックします。
私のGitHubページは次のようになっているとしましょう。
index.html
/changsets
+--0.0.1.json
+--0.0.2.json
...
+--1.0.0.json
changsets dir内のすべてのJSONファイルは、その名前のバージョン以降に変更されたファイルのリストを保持します。1.0.0が現在のバージョンの場合、ファイル1.0.0.jsonには空の配列が含まれます。
バージョン番号の形式はどうあるべきですか？1.0.55または1.55.21の場合、3つの整数はあまり見栄えが良くない可能性があります。いつ開発からマスターブランチに変更をプッシュする必要がありますか？私はJoomla/Drupalチームのような経験がないので、バージョンXをリリースするために実行するスケジュールや機能のリストはありません（ほとんどの更新は確かにバグ修正になります）。
バージョンが頻繁に変更される場合は、時間とリソースの両方を浪費する数十のJSONファイルを生成する必要があります。たぶん、チャンセットが生成されない6か月の期限が必要ですか？
それを処理するためにRESTAPIを備えたWebサーバーが必要なことはわかっていますが、プロジェクトをGitHubで完全にホストする必要があります。