fix: restore voicevox_core-ios-xcframework-cpu-{version}.zip

[qryxip]

内容

#1056 で改名される前のvoicevox_core-ios-xcframework-cpu-{version}.zipを、macOS入りXCFrameworkの横に並べる形で残すようにする。 #1056 が0.16.0 → 0.16.1における破壊的変更になるのを防ぐのが目的。

実装についてはCORE 0.17をそろそろ出していいのではという考えもあり、0.17を出す際にリバートが容易になるよう、#1056以前の機構のコピペを追加するという形にした。

Discordでの話: https://discord.com/channels/879570910208733277/893889888208977960/1397191749805281374

関連 Issue

その他

• ❌ https://github.com/qryxip/voicevox_core/actions/runs/16550814817
• ✔️ : https://github.com/qryxip/voicevox_core/actions/runs/16551275673
  https://github.com/qryxip/voicevox_core/releases/tag/0.16.1-dev.20250727214422

[qryxip]

283ab86 (#1113)
#1056 以前のmake_ios_xcframework.bashも必要になったので、make_compat_ios_xcframework.bashという名前で復活させた。ただしディレクトリ名の変更に対応するという変更は入れた。これでビルドが通るようになった。

[Hiroshiba]

個人的には、今回は何もせずにしれっと名前変更して、名前を変更しましたとリリースノートを書くだけでいいのかなとも思っています！
同じパッケージが2つあることは結構不健全だと思っていて、それはそれで説明が必要というか、できれば避けた方がいいかなと。

というのと、せっかくなのでこの機会にちょっとブランチ戦略を考えた方が良いのかもと思いました！
あるいはバージョン戦略かも。

このPRは破壊的変更に位置するで、普通なら0.17.0にバージョンを上げてしまえばいいと思うんですよね。
僕も名前変更だけでバージョンを上げるのはどちらかというと反対というか、大げさだと思います。
プライドとブランド戦略がそう思わせてるんだと思います。
ユーザーにとっては別に0.17.0でも問題なさそうなので･･･。

でもバージョンは上げず、いびつな状態にするワークアラウンドを取ろうって感じだと思います。
今回はワークアラウンドの手法が取れますが、ワークアラウンドの手法が取れない時もあると思います。
なのでそういうときのことも考えつつ、今回どうするかも考えると良いのかなぁと。

バージョン上げしない方法としては、メジャーバージョン用のブランチを作るとか、逆にマイナーアップデート用ブランチを作るとかがありそう。
あるいは、破壊的変更になるものはマージをずっとせずにちょっと待っていただくとかも不可能ではなさそう（追従大変だけど）。

個人的には、理想を求めると運用コストが高くなって辛くなりそうなので、急いで必要な変更はマイナーバージョンアップ（パッチバージョンアップ）で行って、破壊的変更や機能追加はメジャーアップデートにしちゃうのが楽で良いかなーと思いました！
エンジンとエディタがこの方式に近そうです。

[qryxip]

個人的には、今回は何もせずにしれっと名前変更して、名前を変更しましたとリリースノートを書くだけでいいのかなとも思っています！
同じパッケージが2つあることは結構不健全だと思っていて、それはそれで説明が必要というか、できれば避けた方がいいかなと。

個人的にはどっちも説明は必要で、であればできる限り配慮はしましたと言えるような形の方がいいかなという気持ちです。

個人的には、理想を求めると運用コストが高くなって辛くなりそうなので、急いで必要な変更はマイナーバージョンアップ（パッチバージョンアップ）で行って、破壊的変更や機能追加はメジャーアップデートにしちゃうのが楽で良いかなーと思いました！
エンジンとエディタがこの方式に近そうです。

こちらも個人的な考えですがエディタとエンジンはアプリケーションで、コアはライブラリであるということは意識した方がよいのではないかと思っています。

特にコアは0.16以降、「話者追加アップデート」という概念が消失しています。代わりに「非破壊的変更アップデート」と「破壊的変更アップデート」を分けて提供できるというメリットは結構大きいはずなので、ここを手放すのはちょっと一度深く考える必要があるかなと。

[Hiroshiba]

なるほどです。

一番良いのはこのワークアラウンドをいれることではなく、revertだと思います。
外向きに説明が不要なので一番労力が少ないはず。
というのでどうでしょう･･･！！

こちらも個人的な考えですがエディタとエンジンはアプリケーションで、コアはライブラリであるということは意識した方がよいのではないかと思っています。

ちょっとここはよくわからなかったです･･･！
エンジンも名前が変わると自動DLしている場合エラーになるので、別に条件は変わらないかなーとか思いました。

[qryxip]

ちょっとここはよくわからなかったです･･･！
エンジンも名前が変わると自動DLしている場合エラーになるので、別に条件は変わらないかなーとか思いました。

言葉足らずでした。ユーザーが認識しうる範囲がWeb APIよりも広く、ゆえに破壊的変更が起きる余地が少なくとも VOICEVOX/voicevox_project#18 よりはずっと多い、という意味でした。なのでせめて非破壊的変更アップデートと破壊的変更アップデートは分離した上で、破壊的変更はできるだけまとめるようにした方が、リリース頻度は保ったままユーザーを振り回す回数は減るのではないかと思った次第です。

このPRで問題にしているようなリリース名の変更は、コアでもエンジンでも同様だと思います。

[Hiroshiba]

あ、なるほどです！

どういうブランチ戦略・リリース戦略にしていくのかは余裕あるときに決めておいたほうが良さそうだと思います。
僕が思いついている流れだと以下かなぁと。もちろんこれ以外に良い方法があればって感じですが。

バージョン上げしない方法としては、メジャーバージョン用のブランチを作るとか、逆にマイナーアップデート用ブランチを作るとかがありそう。
あるいは、破壊的変更になるものはマージをずっとせずにちょっと待っていただくとかも不可能ではなさそう（追従大変だけど）。

issue作っちゃうとかどうでしょう？