如何进行存根版本管理？
本节将介绍存根（stub）的版本管理，您可以通过多种不同方式进行处理：
API 版本控制
版本控制究竟意味着什么？如果你指的是API版本控制，有以下几种不同的方法：
-
使用超媒体链接，并且不要通过任何方式对API进行版本控制
-
通过头部和URL传递版本信息
我们不会试图回答哪种方法更好的问题。你应该选择最适合你需求并能创造商业价值的方法。
假设您确实对API进行了版本管理。在这种情况下，您应该为您支持的每个版本提供尽可能多的合约。您可以为每个版本创建一个子文件夹，或者将其附加到合约名称中——选择最适合您的方式即可。
JAR 版本控制
如果你所说的版本是指包含存根的 JAR 的版本，那么主要有两种方法。
假设您正在进行持续交付和部署，这意味着每次通过流水线时都会生成一个新的jar版本，并且该jar可以随时投入生产。例如，您的jar版本可能如下所示（因为它是在2016年10月20日20:15:21构建的）：
1.0.0.20161020-201521-RELEASE
在这种情况下，你生成的存根jar文件应该如下所示：
1.0.0.20161020-201521-RELEASE-stubs.jar
在这种情况下，你应在 application.yml 或 @AutoConfigureStubRunner 中引用存根时，提供存根的最新版本。你可以通过传递 + 符号来实现。以下示例展示了如何操作：
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
但如果版本号是固定的（例如 1.0.4.RELEASE 或 2.1.1），则必须设置 jar 版本的具体值。以下示例展示了如何为版本 2.1.1 进行设置：
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})
开发或生产环境存根
你可以操作分类器，针对其他服务的当前开发版本存根或已部署到生产环境的存根运行测试。如果你修改构建配置，在生产部署时使用 prod-stubs 分类器部署存根，就可以在一种情况下使用开发存根运行测试，在另一种情况下使用生产存根运行测试。
以下示例适用于使用开发版本存根的测试：
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
以下示例适用于使用生产版本存根的测试：
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})
你也可以在部署流水线的属性中传递这些值。