speaker引数をdeprecatedにすると、旧バージョンとの互換性が失われがちになる

[Hiroshiba]

不具合の内容

仕様をすごく迷ってます。

0.15で、スタイルID（style_id）のことを話者ID（speaker_id）としているコードを全部置き換えるということをしようとしています。
追記:結局やめて、全て旧仕様（speaker）に戻しました
APIもspeakerはdeprecatedにし、style_idを推奨する形に変更しようとしています。互換性はあるので問題ないかなと思ってました。

ただ、もしサードパーティーアプリを作る際に最新版のVOICEVOX ENGINEに合わせると、他のエンジンを叩いた時にエラーになることに気づきました。
これをどうしようかすごく迷っています。

影響があるのはstyle_idを受け取っているAPI全部と、あとAPIの名称に「speaker」とあったAPI（/initialize_speaker）などです。

再現手順

ボイボエンジンに合わせてサードパーティアプリを作り、ポートを変えて他のエンジに対応させようとすると、そのままだとエラーになる。

期待動作

期待動作が分からないでいます･･･。いくつかやり方がある気がします。

1. ボイボエンジンは最新APIにし、旧仕様のAPIはdeprecated warningを出しつつ対応する
   • サードパーティアプリを作って他のエンジンに対応しようとした時にめんどくさいかもしれない
     • めんどくさいと言ってもそこまでじゃないかもしれない
   • APIのバージョンを取得するAPIを生やしても良いかも
     • 非対応エンジンには生えてないからエラーになるけど･･･
   • 結局ボイボエディタは互換性を重視するのでdeprecatedなAPIを叩き続ける
     • ログに毎回「非推奨です」と出てくる
       • 非推奨APIでもwarningを出さない起動引数を作る手もある
     • 間違えて互換性のない新しいAPIを叩いてしまう可能性もある
       • これがかなり危ない気がする
2. speaker引数・APIに戻す
   • speaker引数なのにstyle_idを投げないといけない、というややこしさが元に戻る
     • けどまあ1も1でややこしい
   • これが一番手っ取り早い
3. どのAPIバージョンを提供するか起動引数で選べるようにする
   • ボイボエディタからは旧バージョンAPIとして起動すればいいようになる
   • デフォルトはもちろん新バージョンAPIで
   • サードパーティアプリ開発者が他のエンジンを叩こうとした時に変更が必要な点は変わらない

とりあえず0.15は2の方針がいいのかなと思っています（時間がないので。。。。）
追記:0.15は結局2の方針で進んでます

その他

何かもっと良い方法があれば･･････。

[Hiroshiba]

@y-chan 忙しいところすみません、メンテナ意見聞けると。。。。 🙇

（とりあえず2の方針でPR作ってみます）

[sabonerune]

deprecatedと記載しつつも0.x～1.xの間はずっとエディタ側は使用し続けて2.0リリース時に一斉に削除するとか？

[Hiroshiba]

@sabonerune 意見感謝です！！　ありだと思うのですが、

• このエンジン（style_id引数）でサードパーティアプリを作ったあと、他のエンジン（speaker引数）に対応しようとした時にめんどくさいかもしれない
• エディタ側で、間違えて互換性のない新しいAPIを叩いてしまう可能性がある

のは懸念点かなと感じています。
（どれもメリットデメリットあるので、決め方が難しい･･･。）

[sevenc-nanashi]

APIのバージョンを取得するAPIを生やしても良いかも
0.15未満エンジンには生えてないからエラーになるけど･･･

engine_manifestはどうでしょう？apiVersionパラメータみたいな。
または/v2みたいに生やすのもありかも。
エディタ側はいい感じにv1（v0？）とv2を翻訳するオブジェクトを作るとかするとかはどうでしょう。

[vyv03354]

旧エディタから新エンジンを呼び出したときも問題ないようにしたいという観点から考えてみました。旧バージョンのマルチエンジン対応クライアント(具体的にはCOEIROINK v1など)でこの組み合わせになる可能性があります。

この場合、3でも(デフォルトを旧APIにしない限り)互換性のない新APIを叩いてしまう可能性があります。サードパーティアプリでも、起動時引数を指定できるように作られていない可能性があります。たとえばYMM4は設定UIを見る限り指定できないようです。バージョンアップですぐに対応してくれるかもしれませんが、エンドユーザーが起動時引数を正しく指定しないと互換性のないAPIを叩いてしまう可能性があるというのがそもそも嬉しくないです。

engine_manifestにバージョンを追加しただけでは、旧エディタは見ないのでやはり互換性のない新APIを叩いてしまう可能性があります。確実に避けるには/v2などを生やすしかないと思います。新エディタから旧エンジンを呼び出したとき生えていないAPIにアクセスしてエラーになるのを避けるため、engine_manifestへのバージョン追加もあったほうがよさそうです。

[Hiroshiba]

@vyv03354 ご意見感謝です！！
確かに3の場合、旧エディタからエラーになってしまいますね！
仮に新APIで起動したとしても、旧APIは（deprecatedとしつつ）使えないといけない気がします。
これは結局1の形になるので…あまり意味ない気がしますね…。

[tarepan]

speaker 現状維持、という結論が得られたと認識しました。
少なくとも「バグ」「優先度：高」の状態は解消されたため、GitHub Label を変更します。

@Hiroshiba
本 issue での議論は一旦の結論を得たように思います（close 可能？）

[Hiroshiba]

あ、そうですね！
解決していると思います。closeします！