为什么 Turian 2.0.0 只因 1 个小改动就升级为 MAJOR 版本

Turian 2.0.0 发布了。

如果看到“2.0”，你想到的是盛大的发布会、焕然一新的编辑器，以及数百条更新内容，那么这次发布可能会让你意外——而这正是我们的目的。

这次发布只有一个值得重点介绍的变化，而且它是一个破坏性变更。仅凭这一点，版本号就从 1 升到了 2。

为什么升级到了 2.0

直到 v1.17，Turian 的 glTF/GLB 导入器一直存在一个限制：它只会处理文件中第一个 Mesh 的第一个 Primitive，其余内容都会被静默忽略。

对于一个立方体来说，这没有问题。但现实中的模型通常包含几十个 Mesh 和多个材质，因此这个限制已经无法满足实际需求。

Issue #45 解决了这个问题。现在，导入器会处理所有 Mesh 和所有 Primitive，并让每个子网格都绑定对应的材质。

为此，需要同时完成三个修改：

• TMSH（Turian 的内部网格格式）新增了子网格表（Submesh Table），在共享的顶点和索引缓冲区中记录每个 Primitive 的索引范围及材质槽位。
• MeshRendererComponent 将单一的 material 字段改为 materials 数组。
• 场景文件中的 material_guid 字段也改为 material_guids 数组。

最后这一项会影响 Turian 写入你的项目中的场景文件。

使用 2.0.0 保存的场景，将无法被 1.x 完整理解。

根据我们的版本发布策略，这属于破坏性变更，而破坏性变更意味着一次 Major 版本升级。

我们不会等到一年一次的大版本发布。

也不会把一堆毫不相关的修改攒到一起，只为了办一场盛大的发布会。

修改完成了，版本号就升级。

为什么我们这样对待 Major 版本

很多游戏引擎把 Major 版本当作一种品牌。

Unity 6、Unreal 5、Godot 4——这些数字代表着数年的开发成果、大量的新功能，以及不可避免的大量破坏性变更。

因此，很多团队都会在项目开始时锁定一个引擎版本，并一直坚持到项目结束，因为没人能够准确评估跨越一次 Major 版本究竟要付出多少成本。

这种升级“悬崖”并不是突然出现的。

它们往往只是几十个甚至上百个破坏性修改，被长期积压之后，一次性集中发布的结果。

Turian 则反其道而行。

版本号不是营销活动。

它只是一个兼容性信号。

你得到什么

迁移总是在变化还很小、大家还记得为什么这么改的时候发生。

2.0.0 的迁移指南只有一页，看完并完成迁移只需要几分钟。

版本号因此变得诚实。

Major 版本变化，意味着值得阅读迁移指南。

Major 版本没有变化，就意味着即使经过几十次更新，你的源码依然保持兼容。

与此同时，我们也不需要把破坏性修改一直积压到某个“允许破坏兼容”的未来版本。

正是这种积压，才最终导致了其他引擎令人望而生畏的大升级。

还有一个容易被忽略的好处：每一次破坏性修改都是局部的。

修改原因依然清晰，迁移范围非常有限，讨论也只围绕一个设计决策展开，而不是几十项毫无关联的变化。

升级因此变成了一项日常工程工作，而不是一个需要数周规划和风险评估的大项目。

这同样有利于 API 的长期设计。

兼容性很重要，但它并不是绝对不能打破的原则。

当长期收益明显大于迁移成本时，我们就可以改进 API，而不用把那些当初无意形成的设计永远保留下去，只因为它们必须等到那个“神话般的下一个大版本”。

你失去什么

版本号本身会越来越难记。

未来会有 Turian 7、Turian 12……

但这些数字本身不会再承载太多意义。

“2.0”听起来远比实际发生的事情更重大——这也是写下这篇文章的原因。

当然，你会更频繁地遇到迁移，只不过每一次迁移都会刻意保持足够小。

我们认为，这是一笔非常值得的交换。

今天，以及未来

当然，我们也必须承认，Turian 仍然处于项目的早期阶段。

目前用户数量还很少，也没有任何商业项目依赖它，因此这套策略今天造成的影响自然有限。

但这并不是我们采用它的原因。

我们的目标，是在生态真正成长之前，就建立一套可以长期坚持的工程习惯。

随着越来越多的项目——以及未来的商业游戏——建立在 Turian 之上，每一次破坏性修改都会经过更加谨慎的评估。

发布时间是否合适？

迁移成本是否合理？

社区怎么看？

收益是否真的值得打破兼容性？

这些都会成为未来的重要考量。

改变的是门槛，而不是理念。

随着用户越来越多，引入破坏性修改的标准只会越来越高。

目前，Turian 也没有提供 LTS（长期支持）版本，或任何类似的稳定分支。

对于一个仍在快速发展的项目来说，同时维护多个受支持版本，只会增加复杂度，而不会带来相应的价值。

随着 Turian 的成熟，发布流程也会一起成熟。

未来提供 LTS、更长期的兼容性保证，或者其他稳定策略，都完全有可能成为正确的选择。

今天采用的流程，只是最适合今天这个阶段的 Turian，并不意味着它永远不会改变。

新功能不会等待“大版本发布”

这种理念还有一个结果：版本号和沟通方式成为了两件不同的事情。

新的功能、改进和 Bug 修复仍然会像以前一样持续发布。

你可以因为新的导入器、更好的渲染器，或者新的开发工具而升级。

也可以只是为了获得 Bug 修复，而完全忽略那些新增功能。

Major 版本的出现，并不会改变 Turian 的开发节奏。

但有意思的是，在信息传播这件事上，我们几乎采取了相反的策略。

我们不会为每一个新功能单独写一篇博客。

相反，我们更倾向于定期整理成类似于《2026 年 6 月更新汇总》这样的文章。

这样能够把多个改进串联成一个完整的故事，更容易让用户、旁观者，以及媒体理解 Turian 的发展方向。

与此同时，每天的开发过程本来就已经实时公开在开发者真正会查看的地方：提交记录（Commits）、Merge Requests、Issues、Release Notes，以及各种讨论。

这样既保证了技术信息始终保持最新，也避免博客被大量零散的小公告淹没。

版本号回答的是一个问题：

“我需要关心兼容性吗？”

而更新汇总回答的是另一个问题：

“最近 Turian 都有哪些新变化？”

把这两个问题分开，反而让它们都更加清晰。

你需要做什么

几乎什么都不用做。

1. 升级到 2.0.0。 已处理过的网格会在第一次打开时自动重新生成。
2. 运行 turian-cli migrate <project>。 它会把仍然使用旧 material_guid 字段的场景文件更新为新格式。旧场景仍然可以加载，只是会显示一条警告。
3. 如果你的代码使用了 MeshRendererComponent.material， 请改用 materials[0]（必要时同时使用 material_count）。

完整的迁移步骤，以及唯一不要做的事情（使用 2.0.0 保存场景后再用 1.x 打开），都可以在 v2.0.0 迁移指南 中找到。

最后还有一个额外的好消息。

那些原本就包含多个 Mesh 和多个材质的模型，现在终于能够被完整导入了。

如果你以前曾遇到过模型莫名其妙缺失一部分内容，那么这次更新很可能已经解决了这个问题。