AzerothCore

项目版本管理

我们使用语义化版本标准：

http://semver.org/spec/v2.0.0.html

例如，我们可以有：1.5.1-dev.1，它对应：MAJOR.MINOR.PATCH-PRERELEASE

更详细地说：

• MAJOR（主版本）：当你做出不兼容的 API / 数据库结构变更时递增。在 AzerothCore 中，我们会偶尔发布一个主版本，并在发布后仅提供安全修复支持（请阅读下面的章节）。因此，这个版本可以更多地被视为一个里程碑（Milestone）。

• MINOR（次版本）：当你以向后兼容的方式添加功能时递增。这在 AC 上基本不使用，因为我们在发布主版本后不会引入任何新功能。

• PATCH（修订版本）：当你进行向后兼容的 bug 和安全修复时递增。

• PRERELEASE（预发布）：这就是 semver 标准中所谓的"元数据"。我们在 master 分支上工作时会使用这部分版本号。每当有新的功能或破坏性变更（无论是代码还是数据库）发布时，这个数字就会增加，以提醒你可能需要采取的行动。请查看如何使用更新日志。

预发布优先

AzerothCore 尚不被视为"已完成"的软件，因此始终处于开发阶段。上述版本管理主要用于提供一种简单的方法，来检查模块、脚本或任何与 AC 相关的内容是否与 AC 兼容，以及如何进行升级。

我们的策略是（按最常见的操作排序）：

• 当变更只是小修复/琐碎改动时不更新版本
• 当有破坏性变更或新功能时，更新 master 上的 -dev.x 预发布版本
• 当我们决定发布新的稳定版本时升级主版本
• 如果已发布的主版本中引入了任何新的安全补丁或功能，那么这些将增加次版本/修订版本号，不过我们很少这样做。

开发阶段

• 阶段 1：开发阶段：在开发阶段，我们将使用 master 分支，可以自由地对 API、数据库以及所有可能破坏与旧版本兼容性的内容进行更改。在每个开发阶段开始时，我们会清理 sql/updates 文件夹，归档旧的 SQL 文件。

  N.B.

  • 一些大型工作，例如重写/实现功能，可能无法在下一个版本中完成，最终会被规划到未来的版本中，因此它们会保留在专门的分支中，而不是 master。
  • 使用 master 分支，你可以立即获得精彩的新功能，但必须小心，因为在极少数情况下，某些提交可能会破坏稳定性。

• 阶段 2：仅稳定性与安全修复：在此阶段，我们将停止引入机制/内容修复，只对安全性和稳定性问题提供支持。例如：如果某个函数因空指针导致崩溃，我们会修复它。

  如果很多人要求，我们最终可能会延长这一阶段。

• 阶段 3：生命周期结束（EOL）：我们将归档该版本，当然会保留文档和分支。你可以继续使用/下载它，但我们不会提供任何形式的官方支持

版本发布列表

注意：此信息已过时，请查看我们在 GitHub 上的发布