跳到主要内容
版本：v3

TapSDK 版本与维护周期

版本划分规则​

TapSDK 是我们提供的众多服务的总称，为了方便开发者按需接入，我们将每一个子服务使用一个独立模块来对外提供服务，例如：TapTap 登录对应 TapLogin 模块，公告系统对应 TapBillboard 模块，等。

我们使用语义版本号来为 TapSDK 规划版本，版本格式主要分为三部分：主版本号.次版本号.修订号，其中：

  • 主版本号：标记一系列功能和 API 接口的集合，如果某次更新引入了不兼容的 API 修改，我们会升级主版本号；
  • 次版本号：针对向下兼容的功能性新增，我们会升次版本号。例如在原来 3.4.0 的基础上，我们新加入了客服模块，那么就会以 3.5.0 来发布新版本；
  • 修订号：我们修复了 SDK 的 bug 或者对内部实现进行了优化，并且保持对外接口不变时，会升级修订号；
  • 先行版本，以及因为部分平台的特殊限制我们有时也会把平台信息加到「主版本号.次版本号.修订号」的后面，作为延伸。

目前我们开发的主线是 3.x 版本，各平台的 SDK 版本和变更列表，可以参考如下链接：

版本维护生命周期​

每一个大版本，如果是我们开发/维护的主线版本，那么会持续维护——目前 3.x 版本的 SDK 即是如此。如果不是主线版本，则我们会在停止新功能开发之后继续维护两年。假如现在最新的版本是 3.16.5，而下一次迭代，我们改变了对外接口，整个开发主线切换到 4.x 版本，那么从 4.0.0 发布之时起算，我们还会继续维护 3.x 两年的时间——期间只改 bug，不新增功能；两年之后 3.x 版本就彻底停止维护。

对于当前主线下的小版本（例如 3.1.x/3.2.x 版本），如果发现了 bug，我们会在当前最新的版本上进行修复（而不是在 bug 被发现的小版本上进行修复），由于次版本号之间接口完全兼容，并且子功能大都是采用独立模块来发布（模块之间无影响），所以开发者可以无负担地升级到最新次版本号。

我们可以看一个实际的例子。例如某开发者使用了实名认证和防沉迷功能，主要是接入了 TapLogin/BootStrap/AntiAddiction 三个模块，接入时的版本是 3.5.3，而当前最新的版本已迭代到了 3.10.4。后来：

  • 开发者发现并报告 SDK 的一个新 bug，我们跟进修复并发布 3.10.5 版本，开发者可以直接将对应模块版本从 3.5.3 升级到 3.10.5；
  • 而假如开发者发现并报告的问题是一个已经被修复的 bug（例如从 3.8.0 之后该问题已经不复存在），那么开发者可以直接升级到我们当前的最新版 3.10.4。

建议开发者定期更新 TapSDK，保持合理的更新频率以保证客户端的稳定以及更好的用户体验。同时，在有接口的不兼容更新发生前，我们会预先发布 SDK 更新计划；对于即将退出维护周期的 SDK，我们也会提醒开发者及时进行升级。更新计划和升级通知会通过站内信的方式通知各位开发者，在收到站内信通知后，对于需要升级 SDK 的开发者需要尽快更新，避免带来功能或者收益上的影响。