たった1つの小さな変更でメジャーバージョンになった Turian 2.0.0

Turian 2.0.0 をリリースしました。

「2.0」と聞くと、大規模な基調講演や刷新されたエディター、何百項目もの新機能一覧を期待するかもしれません。しかし今回のリリースはそうではありません。そして、それこそが狙いです。

今回のリリースに含まれる目立った変更はたった1つ。しかも、それは破壊的変更です。それだけの理由で、バージョン番号は 1 から 2 へ上がりました。

なぜメジャーバージョンになったのか

v1.17 までの Turian の glTF/GLB インポーターには制限がありました。ファイル内の最初のメッシュの最初のプリミティブだけを処理し、それ以外は黙って破棄していました。

立方体のような単純なモデルなら問題ありません。しかし実際のゲーム用アセットは、1つのモデルの中に何十ものメッシュやマテリアルを持っていることが珍しくありません。

この問題は Issue #45 で修正されました。現在では、インポート時にすべてのメッシュとすべてのプリミティブが処理され、それぞれのサブメッシュに対応するマテリアルが関連付けられます。

そのために、3つの変更が必要になりました。

TMSH（Turian 独自のメッシュ形式）にサブメッシュテーブルを追加し、共有頂点・インデックスバッファ内で各プリミティブのインデックス範囲とマテリアルスロットを保持するようになりました。
MeshRendererComponent の material フィールドは materials 配列へ変更されました。
シーンファイルの material_guid フィールドも material_guids 配列へ変更されました。

最後の変更は、Turian があなたのプロジェクトのシーンファイルへ書き込む内容に影響します。2.0.0 で保存したシーンは、1.x 系では完全には理解できません。

リリースポリシーでは、このような変更は破壊的変更と定義しています。そして破壊的変更は、メジャーバージョンの更新を意味します。

年次リリースまで待つこともしません。大きな発表ができるまで無関係な変更を溜め込むこともしません。変更が完成したら、その時点でバージョンを上げます。

なぜこのようなメジャーバージョン運用なのか

多くのゲームエンジンでは、メジャーバージョンはブランドのような存在です。

Unity 6、Unreal 5、Godot 4──それぞれの数字は数年分の開発成果、多数の新機能、そして避けられない大量の破壊的変更を意味します。

そのため、多くの開発チームはプロジェクト開始時にエンジンのバージョンを固定し、最後まで更新しないことを選びます。メジャーバージョンをまたぐアップグレードにどれほどのコストが掛かるのか予測できないからです。

こうした「アップグレードの崖」は突然現れるものではありません。何年にもわたって先送りされた破壊的変更が、一度にまとめてリリースされることで生まれます。

Turian はその考え方を逆転させます。

バージョン番号はマーケティングのための数字ではありません。

互換性を示すシグナルです。

得られるもの

移行作業は、小さな変更が起きるたびに行われます。

今回の 2.0.0 の移行ガイドは1ページで収まり、数分あれば終わります。メジャーバージョンが変われば「移行ガイドを読むべきだ」と分かり、変わらなければ何十回リリースされてもソース互換性は維持されます。

さらに、破壊的変更を「次の大きなリリース」まで溜め込む必要もありません。結果として、他のエンジンで見られるような巨大で予測しづらいアップグレードを避けられます。

もう一つの利点は、破壊的変更が常に局所的であることです。

変更理由はまだ開発者全員の記憶に新しく、移行内容も限定的で、議論は一つの設計判断だけに集中できます。アップグレードは数週間かかるプロジェクトではなく、日常的な開発作業の一部になります。

これは API 設計にも良い影響を与えます。

互換性は重要ですが、絶対ではありません。本当に長期的な価値があるなら API を改善できます。そうでなければ、偶然生まれた設計を「いつか来る大きなメジャーバージョンまで変更できない」という理由だけで永遠に抱え続けることになります。

失うもの

バージョン番号そのものは覚えにくくなります。

いずれ Turian 7 や Turian 12 が登場するでしょう。しかし、その数字だけでは特別な意味を持ちません。

「2.0」という響きは、実際よりずっと大きな出来事のように聞こえます。このブログ記事を書いた理由もそこにあります。

また、小さな移行作業には今より少し頻繁に遭遇するでしょう。

私たちは、そのトレードオフには十分な価値があると考えています。

現在とこれから

もちろん、Turian がまだ初期段階のプロジェクトであることも事実です。

現在の利用者はまだ少なく、商用タイトルも存在しません。そのため、この方針による影響は現時点では限定的です。

しかし、だからこの方針を採用したわけではありません。

エコシステムが大きくなる前に、予測しやすい開発プロセスを確立しておきたいのです。

将来、より多くのプロジェクトや商用ゲームが Turian を利用するようになれば、破壊的変更はより慎重に計画されるようになります。タイミング、移行コスト、コミュニティからのフィードバック、そして本当に互換性を壊すだけの価値があるのか──そうした点を今以上に慎重に検討する必要があります。

変わらないのは哲学です。

変わるのは、破壊的変更を認めるための基準です。

現時点では LTS や長期安定版も提供していません。

まだ若いプロジェクトで複数のサポートブランチを維持することは、得られるメリットよりも管理コストの方が大きいからです。

将来、プロジェクトが成熟すれば、リリースプロセスも成熟していきます。LTS や長期互換性保証などが適切になる日も来るでしょう。

現在の運用は、「今の Turian」に最適なものを選んでいるだけであり、これが永遠に続くと考えているわけではありません。

新機能は「大きな発表」を待たない

この哲学の結果として、バージョン番号と情報発信は別の役割を持ちます。

新機能や改善、バグ修正は、これまで通り継続的にリリースされます。

インポーターの改善、新しいレンダラー、新しい制作ツールが欲しいからアップデートすることもできますし、単にバグ修正だけを取り込み、新機能を使わないという選択もできます。

メジャーバージョンになったからといって、開発ペースが変わるわけではありません。

一方で、面白いことに、情報発信についてはほぼ逆の考え方を採っています。

個々の機能ごとにブログ記事を書くのではなく、2026年6月リリースのような定期的なまとめ記事で紹介する方針です。

そうすることで、複数の改善を一つのストーリーとして伝えられます。利用者だけでなく、Turian に興味を持ち始めた人やメディアにとっても理解しやすくなります。

一方、日々の開発状況は、開発者が普段見ている場所──コミット、マージリクエスト、Issue、リリースノート、ディスカッション──でリアルタイムに公開されています。

これにより、技術情報は常に最新の状態で共有しつつ、ブログが細切れの告知で埋め尽くされることもありません。

バージョン番号が答えるのは一つだけです。

「互換性について考える必要があるか？」

まとめ記事が答えるのは別の問いです。

「最近の Turian は何が変わったのか？」

この二つを分けることで、どちらもより分かりやすくなります。

あなたがやること

やることは、ほとんどありません。

2.0.0 にアップデートします。 変換済みメッシュは初回起動時に自動で再生成されます。
turian-cli migrate <project> を実行します。 古い material_guid フィールドを新しい形式へ書き換えます。古いシーンも引き続き読み込めますが、警告が表示されます。
もし MeshRendererComponent.material を使っていた場合は、 materials[0]（必要に応じて material_count と併用）へ変更してください。

詳しい手順や、絶対にやってはいけないこと（2.0.0 で保存したシーンを 1.x で再度開くこと）については、v2.0.0 移行ガイドをご覧ください。

最後にもう一つ嬉しい副作用があります。

以前から複数のメッシュやマテリアルを含んでいたモデルが、ようやく完全な状態でインポートされるようになりました。

もし以前、「なぜかモデルの一部が消えている」と感じたことがあるなら、このリリースで解決しているはずです。