Exchange API
Versioning
Assets in Exchange use semantic versioning. Each version number has a major version, minor version, and patch version, separated by periods.
For example, version 1.2.3 has major version 1, minor version 2, and patch version 3.
When to Change Version Numbers
Each time you change an asset, change the version number to indicate the type of change.
1) Always increase the major, minor, or patch version by adding one.
For example, increase from 1.2.9 to 1.2.10, then to 1.2.11.
2) Increase the patch version when you make a bug fix that is backward compatible.
For example, increase from 0.0.3 to 0.0.4.
3) Increase the minor version and reset the patch version to zero when you add functionality that is backward compatible.
For example, increase from 0.2.4 to 0.3.0.
4) Increase the major version and reset the minor and patch versions to zero when you make a change that is not backward compatible.
For example, increase from 7.3.5 to 8.0.0.
Unofficial Conventions
- Initial development usually uses a major component of zero, such as
0.y.z. - When the code is used in production, increase to a major component of one or higher, such as
1.0.0.
API Versioning
For more information, see: