配布パッケージに関する概念
OSファイルシステム、プログラミング言語のモジュールシステムを含めて、名前空間の管理が問題だな、結局。
- リポジトリとパッケージが1:1対応すると簡単だし望ましい。が、たぶん将来的には1リポジトリで複数パッケージのサポートが必要かもしれない。（しばらくは考えないが。）
- パッケージはプロジェクトにインストール（導入）される。
- パッケージのインストールでプロジェクトに導入された機能性をフィーチャと呼ぶことにする。
- パッケージとフィーチャは1:1対応しない。なぜなら、Catyでは、1つのパッケージを複数のアプリケーションに導入することがあるから。
- プロジェクト（＝サイト、サーバーインスタンス）に対する何らかの変更はモディフィケーションと呼ぶことにする。
- インストールはモディフィケーションだが、より一般的には、フィーチャのcreate, update, deleteがある。
- モディフィケーションIDは、「パッケージ名＋パージョン＋日時（秒まで）」とする。モディフィケーションIDのスコープはプロジェクトである。
- ひとつのモディフィケーションで、1つのフィーチャが導入、または更新、または削除される。
- モディフィケーションでは、パッケージの依存関係を調べる必要がある。
- フィーチャは、もとのパッケージとモディフィケーションパラメータにより決定される。
- モディフィケーションパラメータでもっとも重要なものはターゲットアプリケーションで、これは特別扱いしたほうがよい。
- すべての管理されたファイルの操作（create, update, delete）は、そのモディフィケーションを追跡できなくてはならない。
- すべてのモディフィケーションは記録されべき（完全なログ）。
- 現在のファイル状態は維持されるべき。例： status/currentFiles.json
- 現在のフィーチャ状態は維持されるべき。例： status/currentFeatures.json
