跳到主要内容
版本: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 的开发者需要尽快更新,避免带来功能或者收益上的影响。