Product Roadmap and releases
Implementation using ApiRTC versions before 5.0 will stop working on June 30th. Please update to later version
How to migrate ApiRTC version.
We acknowledge that you need stability from the ApiRTC library. Stability ensures that reusable components and libraries, tutorials, tools, and learned practices don't become obsolete unexpectedly. Stability is essential for the ecosystem around ApiRTC to thrive.
We also share with you the need for ApiRTC to keep evolving. We strive to ensure that the foundation on top of which you are building is continuously improving and enabling you to stay up-to-date with the rest of the web ecosystem and your user needs.
This document contains the practices that we follow to provide you with a leading-edge application development platform, balanced with stability. We strive to ensure that future changes are always introduced in a predictable way. We want everyone who depends on ApiRTC to know when and how new features are added, and to be well-prepared when obsolete ones are removed.
ApiRTC version numbers indicate the level of changes that are introduced by the release. This use of semantic versioning helps you understand the potential impact of updating to a new version.
ApiRTC version numbers have three parts: major.minor.patch. For example, version 4.5.3 indicates major version 4, minor version 5, and patch level 3.
The version number is incremented based on the level of change included in the release.
Major releases contain significant new features, some but minimal developer assistance is expected during the update. When updating to a new major release, you might need to run update scripts, refactor code, run additional tests, and learn new APIs.
Minor releases contain new smaller features. Minor releases are fully backward-compatible; no developer assistance is expected during update, but you can optionally modify your applications and libraries to begin using new APIs, features, and capabilities that were added in the release. We update peer dependencies in minor versions by expanding the supported versions, but we do not require projects to update these dependencies.
Patch releases are low risk, bug fix releases. No developer assistance is expected during update.