A CLI which automates semver versioning.

• Requirements
• How to install
  • Github
  • Homebrew
• Usage
• Modes
• How to configure
• Configuration properties
• Examples
• Why SemverBot?

sbot requires a git installation.

sbot can be retrieved from GitHub or a Homebrew tap. Run sbot -h to validate the installation. The tool is available for Windows, Linux and macOS.

sbot is available through github. The following example works for a GitHub Workflow, other CI/CD tooling will require a different path setup.

SEMVERBOT_VERSION=1.0.0
mkdir bin
echo "$(pwd)/bin" >> $GITHUB_PATH
curl -o bin/sbot -L https://github.com/restechnica/semverbot/releases/download/v$SEMVERBOT_VERSION/sbot-linux-amd64
chmod +x bin/sbot

sbot is available through the public tap github.com/restechnica/homebrew-tap

brew tap restechnica/tap git@github.com:restechnica/homebrew-tap.git
brew install restechnica/tap/semverbot

sbot is written in golang, which means you can use go install. Make sure the installation folder, which depends on your golang setup, is in your system PATH.

go install github.com/restechnica/semverbot/cmd/sbot@v1.0.0

Each command has a -h, --help flag available. Support for -v, --verbose and -d, --debug has been added as well.

Gets the current version, which is the latest git semver tag without any prefix. Non-semver tags are ignored.

Generates a configuration with defaults, see configuration defaults.

Gets the next version, without any prefix. Uses a mode to detect which semver level it should increment. Defaults to mode auto. See Modes for more documentation on the supported modes.

Pushes the latest git tag to the remote repository. Equivalent to git push origin {prefix}{version}.

Creates a new version, which is a git annotated tag. Uses a mode to detect which semver level it should increment. Defaults to mode auto. See Modes for more documentation on the supported modes.

Fetches all tags with git to make sure the git repo has the latest tags available. Equivalent to running git fetch --unshallow and git fetch --tags. This command is very useful in pipelines where shallow clones are often the default to save time and space.

Attempts a series of modes in the following order:

1. git-branch
2. git-commit - only if git-branch failed to detect a semver level to increment
3. patch - only if git-commit failed to detect a semver level to increment

Detects which semver level to increment based on the name of the git branch from where a merge commit originated from. This only works when the old branch has not been deleted yet.

The branch name is matched against the 'semver' configuration.

Detects which semver level to increment based on the message of the latest git commit.

The commit message is matched against the 'semver' configuration.

Increments the major level.

Increments the minor level.

Increments the patch level.

sbot supports a configuration file. It looks in the current working directory by default.

Supported default paths:

• .semverbot.toml
• .sbot.toml
• .semverbot/config.toml
• .sbot/config.toml

.json and .yaml formats are not officially supported, but might work. Using .toml is highly recommended.

sbot init generates the following configuration:

mode = "auto"

[git]

[git.config]
email = "semverbot@github.com"
name = "semverbot"

[git.tags]
prefix = "v"
suffix = ""

[semver]
patch = ["fix", "bug"]
minor = ["feature"]
major = ["release"]

[modes]

[modes.git-branch]
delimiters = "/"

[modes.git-commit]
delimiters = "[]/"

sbot supports multiple modes to detect which semver level it should increment. Each mode works with different criteria. A mode flag enables you to switch modes on the fly.

See Modes for documentation about the supported modes.

Defaults to auto.

sbot works with git under the hood, which needs to be set up properly. These config options make sure git is set up properly for your environment before running an sbot command.

git requires user.email to be set. If not set, sbot will set user.email to the value of this property. Rest assured, sbot will not override an existing user.email value.

Without this config sbot might show unexpected behaviour.

git requires user.name to be set. If not set, sbot will set user.name to the value of this property. Rest assured, sbot will not override an existing user.name value.

Without this config sbot might show unexpected behaviour.

Different platforms and environments work with different (or without) version prefixes. This option enables you to set whatever prefix you would like to work with. The "v" prefix, e.g. v1.0.1 is used by default due to its popularity, e.g. some Golang tools completely depend on it.

Note: sbot will always display the version without the prefix.

In case you need a version suffix, this option enables you to set whatever you would like to work with. By default, no suffix is used.

Note: sbot will always display the version without the suffix.

This is where you configure what you think a semver level should be mapped to.

A mapping of semver levels and words, which are matched against git information. Whenever a match happens, sbot will increment the corresponding level.

See Modes for documentation about the supported modes.

sbot works with different modes, which might require configuration.

A string of delimiters which are used to split a git branch name. The matching words for each semver level in the semver map are matched against each of the resulting strings from the split.

e.g. delimiters "/" will split feature/some-feature into ["feature", "some-feature"], and the feature and some-feature strings will be matched against semver map values.

Defaults to "/" due to its popular use in git branch names.

A string of delimiters which are used to split a git commit message.

e.g. delimiters "[]" will split [feature] some-feature into ["feature", " some-feature"], and the feature and some-feature strings will be matched against semver map values.

Defaults to "[]/" due to their popular use in git commit messages. The "/" character is often used in pull request commit messages on GitHub, GitLab and Bitbucket. If somehow the branch name recognition fails, the merge commit message is used as backup.

You can use environment variables to override configuration properties. The environment variable name is the uppercase version of the configuration property name, prefixed with SBOT_. For example, to override the git.tags.suffix property, you can set the SBOT_GIT_TAGS_SUFFIX environment variable.

export SBOT_GIT_TAGS_SUFFIX="-beta"
sbot release version

Make sure sbot is installed.

sbot init
sbot release version
sbot push version

These commands are basically all you need to work with sbot locally.

# installation
SEMVERBOT_VERSION=1.0.0
mkdir bin
echo "$(pwd)/bin" >> $GITHUB_PATH
curl -o bin/sbot -L https://github.com/restechnica/semverbot/releases/download/v$SEMVERBOT_VERSION/sbot-linux-amd64
chmod +x bin/sbot

# preparation
sbot update version
current_version="$(sbot get version)"
release_version="$(sbot predict version)"
echo "CURRENT_VERSION=${current_version}" >> $GITHUB_ENV
echo "RELEASE_VERSION=${release_version}" >> $GITHUB_ENV
echo "current version: ${current_version}"
echo "next version: ${release_version}"

# usage
sbot release version
sbot push version

name: main

on:
  push:
    branches: [ main ]

env:
  SEMVERBOT_VERSION: "1.0.0"

jobs:
  build:
    name: pipeline
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        
      - name: set up path
        run: |
          mkdir bin
          echo "$(pwd)/bin" >> $GITHUB_PATH

      - name: install semverbot
        run: |
          curl -o bin/sbot -L https://github.com/restechnica/semverbot/releases/download/v$SEMVERBOT_VERSION/sbot-linux-amd64
          chmod +x bin/sbot
          
      - name: update version
        run: |
          sbot update version
          current_version="$(sbot get version)"
          release_version="$(sbot predict version)"
          
          echo "CURRENT_VERSION=${current_version}" >> $GITHUB_ENV
          echo "RELEASE_VERSION=${release_version}" >> $GITHUB_ENV
          
          echo "current version: ${current_version}"
          echo "next version: ${release_version}"
          
      # ... build / publish ...
          
      - name: release version
        run: |
          sbot release version
          sbot push version

A typical development workflow when working with sbot:

[create branch 'feature/my-feature' from main/master] > [make changes] > [push changes] > [create pull request] > [approve pull request] > [merge pull request] > [trigger pipeline] > [calculate next version based on branch name] > [build application] > [publish artifact] > [semverbot release & push version]

There are several reasons why you should consider using sbot for your semver versioning.

sbot is originally made for large scale IT departments which maintain hundreds, if not thousands, of code repositories. Manual releases for each of those components and their subcomponents cost a considerable amount of developer time.

1. Standardize how your releases are tagged
2. Automate the releasing process for potentially thousands of code repositories

sbot automates the process of tagging releases for you.

• sbot uses git under the hood, which is today's widely adopted version control system
• sbot does not use a file to keep track of the version
  • no pipeline loops
  • no need to maintain the version in two places, e.g., both a package.json file and git tags
• sbot is ready to be used in pipelines out of the box

Note: it is still possible to use sbot and file-based versioning tools side-by-side

• sbot is designed to be used by both developers and pipelines
• sbot is platform independent
  • support for Windows, Linux and macOS
  • no dependency on 'complex' npm, pip or other package management installations
• sbot heavily simplifies incrementing semver levels based on git information
  • today's git projects already hold a lot of useful semver information, e.g., branch names like feature/xxx or commit messages like [fix] xxx
  • no need to create and maintain custom code for semver level detection

• sbot supports a well-documented configuration file
  • intuitively customize how patch, minor and major levels are detected
• sbot supports several flags to override parts of the configuration file on the fly