#101 バージョン0.4.0未満のプロジェクトファイルへの対応

[Segu-g]

プロジェクトファイルについての操作をstore内のindex.tsからstore内のstore/projectフォルダに移し，store/project/version0.3.0.ts , store/project/version0.4.0.tsのようにプロジェクトファイルの形式を記述する構造にしてみました．
前後のバージョン間のプロジェクトファイルの変換関数(updater)を記述することでマイグレーションを実現しています．
fix #101

[Segu-g]

2021年8月17日現在　mainブランチにおいてソフトウェアのバージョンは0.3.1と設定されており、プロジェクト形式の更新バージョンを0.4.0としています。従って現在のmainブランチから生成されたプロジェクトフォルダは形式が不正となり、自身で読み込むことができません．
バージョン0.3.0 , 0.3.1のプロジェクトファイルは過去のリリースから作成したものを用い、バージョン0.4.0のプロジェクトファイルはmainブランチから作成したプロジェクトファイルに対してテキストエディタ等でappVersionを"0.3.1"から"0.4.0"に書き換えたものを使用してください。

[Hiroshiba]

ソフトウェアのバージョンをプロジェクトファイルのバージョンにするとそういった煩わしさがあるんですね。なるほどです。
releaseブランチを切ってmainブランチのバージョンは先に上げておくか、プロジェクトファイルバージョンを別に作るか、といったところでしょうか・・・
hotfixが入ったときに強い設計にしておきたいのですが、どうすればいいでしょう。

[Hiroshiba]

やりたいこと（プロジェクトファイルのマイグレーションを型レベルで保証する）はとてもかっこいいと思うのですが、ライブラリを管理するくらいの気合が必要な実装だと感じました。

このプルリクエストには0.3.1のプロジェクトファイルを0.4.0へマイグレーションする機能と、マイグレーションのインターフェースの機能が備わっていて、前者は急ぎたい一方、後者は議論が必要で時間がかかるかもしれません。
とりあえずマイグレーションするだけ（load時のバージョンが0.4.0未満ならcharactorをcharacterにreplaceする）のコードをマージして、後者はゆっくり実装していくのはどうでしょう。

[Segu-g]

ひとまず全てのバリデーションチェックを捨て，charactorIndexをcharacterIndexに書き換えるだけのコードをに差し替えました．
マイグレーションのコードはブランチを切ったのでissue等で議論しましょう．

[Hiroshiba]

issueでの議論、良いと思います。
コードもすごくスッキリして良いと思います。　

[Hiroshiba]

先に入った https://github.com/Hiroshiba/voicevox/pull/114 が偶然コンフリクトしているようです。

[Hiroshiba]

remove/addされた行数を比較して気づいたのですが、projectSchemaが消えてValidationがなくなっていそうです

[Segu-g]

意図を勘違いしていたようで申し訳ありません。
バージョン0.3.0と0.4.0のSchemaに対してバリデーションチェックを行いながら、0.3.0の時は0.4.0の型へのキャストを書くという事でしょうか？

[Hiroshiba]

最新版になったものをバリデーションするのが良いのかな、と思っています。

最新版（0.4.0版）をロードした時
json.load　→　validation

0.3.1版をロードした時
json.laod　→　migration　→　validation

という感じです。

[Hiroshiba]

LGTM！