-
Notifications
You must be signed in to change notification settings - Fork 187
TeamsJS library versioning
TeamsJS SDK is using semantic versioning. For convenience, the following has been copied from that link:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
TeamsJS SDK also uses beachball to keep track of the types of changes that are being merged into the library and consequently, at release time, to bump the version accordingly.
This means that the version number of a release reflects the type of changes that were made since the previous release. The version number is not based on any other inputs, e.g. day, year, number of changes, phase of moon, height of engineer, etc.
Changes made in the private folder (which should be rare and consist only of Microsoft-internal functionality) will not be considered MAJOR changes, even if they are incompatible API changes. It would be inconsistent and confusing for our world-wide developers to be presented with a new major version that contains no breaking changes or new major features that affect them.
As mentioned, the release process will use beachball to bump the version (via beachball bump) and it will increment according to the highest order change type found by iterating through the change files created for each merge to main.
At time of writing, the current version is 2.0.0. The highest order change type among the current change files in main is MINOR. As a result, beachball bump returns 2.1.0 for the next version.
If a change is merged to main that is of type MAJOR, then the next official release will have bumped the MAJOR version (e.g., 3.0.0 at time of writing). From an engineering perspective, this could happen at any point in the calendar year.
The beta version will be dependent on the current beta version and the expected next release version, predicted using beachball bump, which iterates through the change files created for each merge to main and sets the next version based on the highest order change type.
If the current beta version is 2.0.0-beta.7, and beachball bump (at time of writing) predicts the next version is 2.1.0 because the highest order change type in the change files is MINOR, the next beta release would be 2.1.0-beta.0. If the current beta version is 2.1.0-beta.0 and the next version is 2.1.0, then the next beta release would be 2.1.0-beta.1.