この状況を想像してください：
- 内部ユーティリティ（レベルエディターなど）があります。 新しいバージョンは随時リリースされます。
- 情報はXMLまたは別のツリーのような拡張可能な形式で保存されます。 同時に、軽量のJediとして、互換性をボトムアップで監視し、それ以降のバージョンではすべての初期プロジェクトを開きます。
- このユーティリティは、専門知識がなく、「早期模倣症候群」の影響を受けない人々によって使用されます。 エディターの最新バージョンを持っている必要はありません。 主なものは安定しており、1つのプロジェクトのフレームワーク内で同じです。
- 新しい関数が随時登場し、これらの関数のXMLに新しいブロックが登場します。 同時に、このような状況が発生する可能性があります。1つのプロジェクトで2つの作業を行います。 1つのプログラムは新しいブロックをサポートしますが、もう1つのプログラムはサポートしません。 2番目のプロジェクトを保存すると、これらのブロックが失われます。
- データストレージ形式を「再描画」する必要がある場合があります。 たとえば、1つのタイルセットが存在する前に、今では完全な束になります。 古いバージョンは「屋根を吹き飛ばす」可能性が高く、ダウンロードする前に次のように警告する必要があります。 ダウンロードを続行しますか？」
- 古いプロジェクトを新しいバージョンで開く場合、同様の確認が必要です。 ユーティリティは内部にあるため、古い保存のサポートを保存することはできません。
- ユーティリティは内部にあるため、「何もないよりもベータ版」であり、完全性の欠如の唯一の保証は私たちのプロ意識です。 データを台無しにする「黒」バージョンが表示される場合があります。 ひどい間違いが彼のバージョンに忍び込んだことをデザイナーに警告するには？
- 集中更新サーバーなしで行う必要があります。
2005年に、このシンプルなソリューションを思いつき、モバイルゲームに取り組んで、どうにかして動物園バージョンに対処しました。
各ドキュメントに4つのフィールドを格納します。
- BuildSaved-プロジェクトを保存したバージョン。
- BuildSupported-このセーブゲームを完全に開くことが保証されている最小バージョン。
- BuildRequired-少なくとも部分的にエラーなしでこのセーブゲームを開く最小バージョン。
- BlackBuilds-データを破損するすべてのバージョン。
同時に、BuildSaved> = BuildSupported> = BuildRequired。 ソースでバージョン番号をハードに設定しました。 XMLに新しいフィールドが登場しました-BuildSupportedを現在のバージョンに置き換えます。 ストレージ形式を再編集します-BuildSupportedとBuildRequiredをすぐに置き換えます。 BlackBuildsは、変更ログによって投機的に判断しました-エラーのある機能が現れたバージョンから、気づいて修正したバージョンまで。
ドキュメントを開いて、このようなチェックを行います。
- プログラムの現在のバージョンがBuildRequiredよりも低い場合は、次のように通知します。 ダウンロードを続行しますか？」
- バージョンがBuildSupportedよりも低い場合、「ドキュメントに新しいフィールドが含まれている可能性がありますが、再保存すると失われます。」
- バージョンがBlackBuildsの1つである場合、「バージョンが文書を台無しにします。 何も保存せず、危険度の低いバージョンにアップグレードしてください。」
- BuildSavedがEXEファイルに保存されている「ブラック」バージョンの1つである場合、「ドキュメントは危険なバージョンによって保存されました。 ドキュメントにエラーがある可能性があります。 ドキュメントを保存した人がすぐに更新されるようにします。
- 最後に、古いデータストレージメカニズムが検出された場合は、「再保存する前にバックアップコピーを作成します」と出力します。 さらに良いことに、自動的にバックアップを作成します（ jayが推奨）。 BuildRequiredの1桁に基づく裸のステートメントは既にありません。フォーマットが古くなっているかどうかを確認するときに表示されます。