リリースポリシー
セマンティックバージョニング
Turian はセマンティックバージョニング（major.minor.patch —— 例：v1.9.0）に従います。
- メジャーバージョンの増加は破壊的変更を意味します——プロジェクトの手動更新が必要になる場合があります。
- マイナーバージョンの増加は機能を追加しますが、既存のコードは変更なしでコンパイルを続けられます。
- パッチバージョンの増加は API 変更なしでバグ修正とパフォーマンス改善を提供します。
私たちはメジャーバージョンを無期限に 0 に保つべきとは考えていません。Turian は v1.0.0 以降 v1.x.x であり、その時点でゼロからゲームを作成し、スタンドアロンの実行可能ファイルにビルドすることが可能になりました。「プロダクション準備完了」はプロジェクトの決定と発表であり、バージョン番号ではありません。
メジャーリリースは技術的なものであり、マーケティングではない
多くのエンジンでは、新しいメジャーバージョンは一大イベントです——何年分もの機能が1つの番号の裏にまとめられ、基調講演で発表され、長く危険な移行作業が続きます。Turian はバージョン番号を文字通りに扱います。メジャーリリースが意味するのはただ1つ——既存のプロジェクトを壊しうる形で何かが変更された——ということだけで、他のリリースと同じ日に出荷され、時にはたった1つの破壊的変更しか含まないこともあります。
保証されること：
- すべてのメジャーリリースには対応する移行ガイドのエントリがあり、何が変更され、（もしあれば）何をする必要があるかを正確に伝えます。
- 破壊的なデータ形式の変更には、変更履歴の一行だけでなく移行パスが用意されます：古いファイルは（警告付きで）引き続き読み込め、バッチツール（
turian-cli migrate）がプロジェクト全体で変換を永続化します。 - 破壊的変更は「大きな」バージョンのためにため込まれるのではなく、完成し次第リリースされるため、それぞれの移行作業は小さく、単独でレビューしやすいものになります。
「Turian の新機能」というストーリーは別の場所にあります：ブログの定期的なまとめ記事が、バージョン番号とは無関係に、複数のリリースにまたがる機能や修正をまとめています。
リリース頻度
私たちは毎日新しいリリースを提供しています（コード変更があった場合）。つまり、バグ修正と機能はマージされた当日に届き、次の「大きな」リリースを何ヶ月も待つ必要はありません。
高頻度リリースの利点：
- 今日報告したバグは明日のリリースで修正されます——四半期ごとのマイルストーンを待つ必要はありません。
- 連続するリリース間の差分が小さいため、リグレッションの追跡が容易です。
- 特定のバージョンに固定し、自分のペースでアップグレードできます。
将来的にプロジェクトが安定したら頻度を減らすかもしれませんが、哲学は変わりません：早くリリースし、頻繁にリリースする。
長期サポート
長期サポート（LTS）リリースは提供していません。プロジェクトは初期段階にあり、API は急速に進化しています。LTS ブランチを維持すると開発が遅れ、コミュニティが分裂します。サポートされているバージョンを使い続ける最善の方法は、最新リリースに従うことです。
複数バージョンのインストール
SDK バイナリリリースは完全に再配置可能で自己完結型です。各リリースは独自のフォルダに展開されるため、複数のバージョンを同じマシン上で競合なく共存できます。SDK にはエンジンソース、エディタソース、依存関係、CLI バイナリ——ゲームのビルドに必要なすべてが含まれています。
~/sdks/turian-sdk-linux-x86_64-v1.8.0/turian-cli build mygame # v1.8.0
~/sdks/turian-sdk-linux-x86_64-v1.9.0/turian-cli build mygame # v1.9.0
各 turian-cli バイナリは、隣接する turian-sdk.json マーカーファイルを通じて自身のエンジンソースを解決します。プロジェクトの出力は、呼び出した正確なバージョンに対して常にコンパイルされます。SDK のレイアウトとバージョン共存の詳細については、インストールページを参照してください。