言語ごとのリリースについて

[qryxip]

内容

現在C APIとPython APIのみをリリースしていますが、今後言語が増えるごとに全言語を同時にリリースすることは厳しくなるかもしれません。というより粒度が合わなくなるかもしれません。そのためリリースについて考える必要に迫られると思います。

Discordでの会話

ヒホ — 08/17/2023 4:21 AM

コアの各言語のラッパー、たぶんコアのバージョンアップに合わせて全言語を同時アップデートするのは優先度的にかなり厳しくなってくる気がしました。
例えば　言語Aラッパーのアプデ優先度 <<< コアアプデの優先度　みたいな。
リリース戦略を考えていく必要があるかも？
（ある程度まとまったらissueにしようと思ってます）

https://discord.com/channels/879570910208733277/893889888208977960/1141451611336622131

ヒホ — 08/17/2023 4:38 AM

要求としてありえそうなのは「エンジンに機能追加したい・緊急修正したい」かなと思いました。
であればやり方はいくらでもありそう。

戦略A　エンジンのみ用をエンジン版バージョンとしてリリース
・0.16-engine.0みたいな
・機能追加はcompatible_engineの変更だけでよく、ラッパーは対応不要なので気軽
・緊急修正はラッパー側も影響がありえる全言語修正する手間が必要

戦略B　↑＋エンジン向けのみのDLLをリリースできるようにする
・ラッパーのことを考えずに緊急修正が可能になる
---
とりあえず戦略Aは取れるようにしておいて、戦略Bも時間あるときに作っておくと良さそう？

https://discord.com/channels/879570910208733277/893889888208977960/1141455967159074967

ラッパー言語間で優先度が変わることがありえると、言語ごとにリリースサイクルを変えたくなりそう 😇
まあでもこれは一旦考えなくていいかなぁ。

https://discord.com/channels/879570910208733277/893889888208977960/1141456299087900864

qryxip — 08/17/2023 6:21 PM

py-v0.15.0みたいなタグで言語ごとに出すのもよい気がしています。言語間の足並みが揃うなら揃うでビルドを同時に起動すればいいはずじゃないかなと
例: Polars (Pandasの後継を狙う、PyO3製のライブラリ)のリリース

https://discord.com/channels/879570910208733277/893889888208977960/1141663150920445995

python-0.15.0のように各言語バラバラにリリースするのを私は提案したいです。特定の言語だけ修正というのも今後はあると思いますし、同時にリリースできるならそのときはそのときで同時に出せばよいと思います。今はActionの無料枠を余計に取るということもないはず。

Pros 良くなる点

Cons 悪くなる点

実現方法

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

[Hiroshiba]

issue作成ありがとうございます！！
着眼点がいくつかあるので整理してみます。

• 需要
  1. C API版を気軽に機能追加・緊急アップデートができること
     • VOICEVOX ENGINE用のため
     • 他の言語をスルーして自由なタイミングでエンジン向けにリリースできれば良い
     • 他の言語だとテストが通らない状態のrelease-[version]ブランチが存在することになる
     • これができないとエンジンがコアに依存しづらいので、製品版VOICEVOX的に優先度が一番高い
  2. 言語個別にリリース・アップデートができること
     • 個々のリリースが早い・含まれるべきファイルなどが明確になる
     • 特定の言語だけ修正できる
     • 1の需要を自動的に満たす

これらの需要に対して、優先度の高いものを率先的に実装する方法と、完璧なものを最初から作る方法がありそうです。

• 手法
  1. 言語ごとにリリースバージョンにprefixをつけ、その言語だけをリリースできるようにする
     • 需要1と2を両方満たす
     • 一番良い方法
     • 現状言語が3つあるのでちょっとだけ改修が大変
  2. C APIだけリリースできるようにする
     • 需要1だけを満たす
     • 優先度の一番高い実装だけをできるので早い

手法1が一番やりたいことで、優先度が高いのが手法2なので、1の方への拡張をできるようにしつつ2の方を実装するのが筋かなと思いました。
この流れはそんなに悪いことじゃない気がします。例えば以下の流れはどうでしょうか。

• prefix無しバージョンはC APIのものとする
• 今のビルドスクリプトを、C APIだけのリリースもできるGithub Workflowにする
  • ONLY_C_APIフラグ引数を作るだけ？
  • ONLY_C_API=falseの時は全言語リリース（今の挙動と一緒）
• 後々にビルドスクリプトを言語ごとに分けられるようにする
  • ビルドスクリプトを分割するとか、どの言語をリリースするのかを選択可能にするとか

この流れであれば拡張も容易ですし、そもそもエンジンの機能追加の需要が発生しなければ最初から手法1の方を実装する流れでも問題なさそうです。
@qryxip どうでしょう 👀

[Hiroshiba]

こちらの方針をどうするか考えて実現することはバージョン0.15リリースに必須要件かもです

• [2月末リリース予定!] v0.16 #545

リリースする流れになって、言語ブランチ周りに時間が割けなさそうだったらONLY_C_APIフラグを実装する流れが良さそう･･･？

[Hiroshiba]

この方針について @qryxip さんと（放送で）ちょっと話しました。

言語ごとのリリース戦略をどうしていくかは分かりませんが、とりあえずバージョン0.15のリリースに関しては、次の2つのことをすればよさそうかなと。

1. CAPIだけリリース（ビルドしてreleasesにアップロード）できるようにする
2. エンジンが依存し始めたタイミングでエンジン用のreleaseブランチを作る（名前未定）

1はやっておくと、コアの破壊的変更をしたい時にエンジンの都合を考えなくて良いので後腐れがない気がします。
2は適当なタイミングでブランチを作ればいいだけなのでコア側にとっては何も考えることはないかも。
というかなんなら、C APIだけリリースできる機能が欲しくなった時点で2を作ってそこに機能を足すという手もあるので、何も気にせずに0.15にアップデートするのも全然ありな気がしました。