Description

1. We use Semantic Versioning
2. We bump MAJOR on a breaking change
3. We bump MINOR on a non-breaking change
4. We use PATCH on release/* branches.

<aside> 👌

Yes, we will end up with a v148.35.0 soon. But this is completely fine, don’t you worry.

</aside>

Tags

1. We use git tags to track the version of the library.
2. Tag format is vX.Y.Z
3. Run ./_assets/scripts/version.sh to get the current version

Tagging a new version

1. Version is calculated automatically based on commit messages
   • ! meaning a breaking change (MINOR increment)
   • _ meaning a non-breaking change (PATCH increment)
2. Run make tag-version to create a new git tag
3. Don’t forget to git push the tag
4. Use the created tag to link mobile client to the new version

Tags and branches

1. Release branches will be release/1.0.x, release/1.1.x etc.

   We will only make them as needed, i.e. when with a desktop/mobile release.

2. Tags on develop branch (with PATCH=0) will be made as needed, same as it's done now

   Basically, when mobile team updates status-go in their repo, because they point to status-go by version tag. Desktop uses status-go as a git submodule, no need for them.

3. Tags on release/* branches (with PATCH>=0) SHOULD be made manually and as needed, when a patch release is made on desktop/mobile.

Change proposals