This documentation explains how to manage brick versions and what are the rules to follow for version management.

Supported version

Brick version needs to be formatted like X.Y.Z where :

• X is the major version
• Y is the minor version
• Z is patch (for fixes)

Beta version

Bricks also supports beta version. Beta version are use to deploy new features that are not fully ready yet. It can be useful to expose new unstable features so users can test them before the next version release.
Beta version look like X.Y.Z-beta.A. The A number represent the version of the beta brick. The X.Y.Z-beta.A version is a preview for the next future version : X.Y.Z.
For example 1.2.0-beta.1 is a beta version and 1.2.0-beta.2 is the next beta version. But both of theses version are beta for the future version1.2.0.
We recommand to only create beta for major and minor version (not for patches). Patches do not need beta version and should be small fixes on the brick. So a beta version should look like X.Y.0-beta.A.

Recommended rules

1. Major versions are released every 6-12 months and include a bundle of new features and some breaking changes.
2. Minor versions are released every 1-2 months and include new features (avoid breaking changes).
3. Patch versions are released when needed and only include bug fixes.
   • They should not include new tasks, protocols or resources.
   • They should not change inputs/outputs or config of tasks and protocols.
   • They should not rename exposed classes or functions.