经过多年的讨论，我们终于准备在Asciidoctor中转换到语义版本控制。这一转换将作为每个参与项目的下一个主要版本的一部分发生。

关于语义版本控制

语义版本控制（简称SemVer）是一种基于简单的MAJOR.MINOR.PATCH序列选择版本号的逻辑系统。

  • 一个主要的版本用于引入不兼容的变化（无论是大的还是小的）。

  • 一个次要版本是用于添加向后兼容的功能。

  • PATCH版本是用于修复错误的（当然，要向后兼容）。

构建元数据也可以包含预发布版本的空间。你可以通过https://semver.org[^]了解更多信息。

在我们目前的系统中，补丁版本与主要和次要版本无法区分，并且只有单一的版本线。经验告诉我们（通过艰难的方式）这种情况既不清晰也不可持续。对我们来说，SemVer是关于更好的沟通和成长空间。这是一个基于共同期望和信任的系统。尽管它可能不是完美的，但SemVer应该有助于理解版本号所涉及的内容以及何时升级。我们不能指望它阻止打破某些东西，但至少你会知道何时可能会这样。

独立版本控制项目

切换到语义化版本控制（SemVer）也意味着Asciidoctor项目，即Asciidoctor、AsciidoctorJ和Asciidoctor.js，将独立进行版本控制。生态系统中的其他项目也很可能开始独立进行版本控制（实际上，一些已经这样做了）。

AsciidoctorJ和Asciidoctor.js都已经到了一个阶段，这些项目已经不仅仅是Asciidoctor RubyGem的再发行版本了。它们拥有自己的API、扩展模型、定制特性以及平台集成。这就值得它们拥有自己的版本线。一个独立的版本线也将让用户更好地理解每个版本中可以期待什么。

在与https://github.com/robertpanzer[Robert]（AsciidoctorJ负责人）和https://github.com/mogztter[Guillaume]（Asciidoctor.js负责人）交谈后，以下是我们达成一致的系统：

  • 核心处理器（Asciidoctor、AsciidoctorJ 和 Asciidoctor.js）将从2.0.0版本开始转移到SemVer版本控制。我们计划所有三个项目在大致相同的时间进行这一主要版本转变，以尽量减少混淆。

  • 如果Asciidoctor.js或AsciidoctorJ需要在Asciidoctor中做出改变，它们可以强制Asciidoctor发布新版本。这意味着Asciidoctor需要在任何时候都准备好“发布”。补丁或小版本更新不需要太多讨论，但是一个主要版本更新当然需要。

  • 在2.0.0版本之后，我们不会试图对齐这三个项目的版本号。Guillaume提出了一个强有力的论点，即试图对齐版本号将违背SemVer原则，从而导致版本号失去其意义。这确实引入了一个复杂性，我们需要记录Asciidoctor.js或AsciidoctorJ提供的Asciidoctor版本。然而，AsciidoctorJ和Asciidoctor.js都提供了一个用于访问底层Asciidoctor发行版版本的API。发行号也可以通过`asciidoctor-version`文档属性访问得到。

我们考虑了如何在依然遵守语义版本控制(SemVer)的情况下，将Asciidoctor、AsciidoctorJ和Asciidoctor.js锁定在相同的版本。然而，我们得出结论，这样做只会延续造成我们所见发布延迟的情况。最好是让这些项目在适当的时间自由发布。而且，拥有三个版本号段（MAJOR.MINOR.PATCH），我们终于有足够的空间让这些发布发生了！

下一步操作

我们将从重新打包Asciidoctor 1.5.8版本作为2.0.0版本开始，同时做一些小的调整以放弃支持旧版本的Ruby。接下来，AsciidoctorJ和Asciidoctor.js也将跟进他们的2.0.0版本发布。到那时，我们将按照上面概述的SemVer规则进行版本控制。