Skip to main content
Version: v3

TapSDK Versions and Maintenance Cycle

Rules for versioning​

TapSDK is the generic name for many of the services we provide. To make it easier for developers to access them on demand, we use a separate module for each sub-service. For example: TapTap Login corresponds to the TapLogin module, Billboard corresponds to the TapBillboard module, and so on.

We use semantic versioning to plan versions for TapSDK. The version is formatted mainly with three parts: MAJOR.MINOR.PATCH, where:

  • MAJOR: Indicates a collection of features and API interfaces. If there are incompatible changes introduced in an update, we will upgrade the MAJOR version number;
  • MINOR: When there are functional additions that ensure backward compatibility, the MINOR version number will be increased. For instance, when a new customer service module is added to version 3.4.0, the updated version will be 3.5.0;
  • PATCH: If we fix a bug in the SDK or optimize its internal implementation while keeping the external interface unchanged, we will upgrade the PATCH version number;
  • When there are pre-released versions or versions released due to platform-specific limitations, we sometimes append the information to "MAJOR.MINOR.PATCH" as an extension.

Currently the main line of our development is the 3.x version. For the SDK versions and changelist for each platform, please refer to the following links:

Lifecycle of version maintenance​

Each major release is continuously maintained if it is a mainline release that we develop/maintain - this is the case for the current 3.x version of the SDK. If it's not a major release, we maintain it for two years** after we stop developing new features. If the latest version is 3.16.5, and in the next iteration we change the external interfaces and move to 4.x, then we will maintain 3.x for two years from the time 4.0.0 is released - there will only be bug fixes and no new features; and then after two years 3.x will be completely deprecated.

For minor versions under the current mainline (e.g. 3.1.x/3.2.x), if a bug is found, we will fix it in the current latest version (not in the minor version where the bug was found). Since the interfaces are fully compatible between minor version numbers and the sub-functions are mostly released as independent modules (no impact between modules), developers can upgrade to the latest minor version without any burden.

Let's look at an example. A developer uses real name authentication and anti-addiction by integrating the TapLogin/BootStrap/AntiAddiction modules from the version 3.5.3, while the latest version is currently 3.10.4. Later:

  • The developer found and reported a new bug in the SDK. We followed up to fix it and released version 3.10.5. The developer can directly upgrade the corresponding modules from 3.5.3 to 3.10.5;
  • If the developer found and reported a bug that has already been fixed (e.g. no longer exists since 3.8.0), then the developer can simply upgrade to our latest version, 3.10.4.

We recommend developers to update TapSDK regularly and keep a reasonable update frequency to ensure the stability of the client and better user experience. Meanwhile, we will publish the SDK update plan in advance of any interface incompatibility update; we will also remind developers to upgrade the SDK that will be out of maintenance cycle in time. The update plan and upgrade notification will be sent to all developers via email. After receiving the email notification, developers who need to upgrade their SDKs must do so as soon as possible to avoid any impact on functionality or revenue.