表現を変えても、ノートの識別情報は保つ

生成したデッキが、最初のエクスポートで完成することはあまりありません。定義を改善し、例を分かりやすくし、誤りを修正していきます。次のビルドでは、どのノートが内容を改善した同じノートなのかを識別する必要があります。

次の小さな編集を考えてみます。

意味の説明は広がりましたが、論理的なノートは同じです。

識別情報を内容から分離する

明示的な安定 ID は、ノートに永続的なキーを与えます。ノートを編集するときは ID を保ち、別の論理ノートを作るときは新しい ID を選びます。

識別情報にはプロジェクトの文脈もあります。同じデッキのリリース間では、プロジェクトの名前空間を揃えてください。ノート ID 単体は、繰り返し実行できる更新手順の一部にすぎません。

次のビルドに基準パッケージを渡す

前回のパッケージは、以前に何をエクスポートしたかを Anki Forge に伝えます。修正したプロジェクトをビルドするときに使います。

let comparison = project.compare(CompareOptions::against(&previous))?;
ensure!(comparison.policy().allows_publication());
let built = project.build(BuildOptions::to(&next).update_from(&previous))?;

この抜粋では、project に修正済みのノートが入り、previous がバージョン1を指し、next はバージョン2の別のパスです。完全な例には両方のプロジェクト定義があり、1件のノートの識別情報が保持されたことを検証します。

入力と出力のパッケージは別のパスに保存してください。基準パッケージを上書きすると、リリースを理解・検証するために必要な証拠を失います。

配布時のオリジナルパッケージを保持する

生成するすべてのパッケージには、完全な識別情報とリビジョンの証拠が含まれます。次のビルドでは、識別情報を再使用する前に、それらの証拠を実際のデータベースとメディアに照らして検証します。配布したオリジナルパッケージを保存してください。Anki から再エクスポートしたファイルは、更新の基準パッケージとして使用できません。

更新ガイドでは、厳密な更新、リスクポリシー、クライアントでのインポートの制約を説明します。

ビルドとインポートを確認する

パッケージを配布する前に、ビルドレポートと更新の安全性に関する診断を確認します。ビルドがノートの識別情報を整合させられない場合は、出力ファイルを更新の正しさの証拠とせず、ソースと基準パッケージを調べてください。

その後、Anki 独自のインポート動作が適用されます。インポート設定、既存ノートの内容、ローカル編集、Anki のバージョンが結果に影響する場合があります。安定した識別情報はノートの照合に役立ちますが、それらの選択を上書きしたり、すべてのインポートでローカル状態のあらゆる側面が保持されると約束したりするものではありません。

2つのバージョンのサンプルには両方のパッケージがあります。自分のリリース手順を設計する前に、小さく確認しやすい更新を試せます。