Written by Henrik Molnes✏️

Most projects I’ve worked on have tried to follow semantic versioning, and it is probably one of the most-used strategies for versioning software.

It has a clear and strict specification. The problem occurs when a developer tries to follow this specification.

Semantic versioning is defined like this: MAJOR.MINOR.PATCH

• MAJOR: breaking changes
• MINOR: add functionality in a backwards-compatible manner
• PATCH: backwards-compatible bug fixes

This often means that, upon a new release, the developer must go through all changes since the last release to figure out the next version number.

This can be a difficult and time-consuming task. Often it leads to sentimental versioning. To avoid this, we must remove all human interaction.

We can achieve that by using semantic-release.

This is a tool installed in the CI environment that examines the commit messages and, on this basis, automatically derives the next version number for the next release.

This means that all the team members must use the same standard when writing commit messages. Conventional commits is a standard that will help us achieve this.

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it a solid base over which to write automated tools.

Since we already established that humans are not trustworthy, we will use a command line tool to generate conventional commits.

The tool will ask the developer some questions and create a commit message from these answers.

This tool is called commitizen, and it’s great for standardizing commit messages. You can install it like this:

npm install -g commitizen

After installing it, we must use git cz instead of git commit -m "commit message". The procedure looks like this:

Example of other commit messages generated from these questions:

When we have the commit messages structured in this format, we can utilize semantic-release. It is meant to be executed on the CI environment after every successful build on the release branch.

In this way, no human is directly involved in the release process and the releases are guaranteed to be unromantic and unsentimental.

Semantic-release is actually an npm package originally only made for Node projects. But by using a plugin, it can be used on all types of projects.

The plugin is called semantic-release/exec, and it provides you with the new version number and lets you execute your own custom commands.

Semantic release is installed like this:

npm install --save-dev semantic-release

To make it work in circleci, the build configuration file will look something like this:

version: 2
jobs:
  release:
    docker:
      - image: circleci/node:8
    steps:
      - checkout
      - run: npm install
      - run: npx semantic-release

workflows:
  version: 2
  make_release:
    jobs:
      - release

Read more about setup for the CI environment here.

To sum it up, we now have semantic-release installed on the buildserver, which analyzes the commit history.

The commit messages follow a standard called conventional commit, with the help of commitezen (installed on the developers computer).

This might seem a bit excessive, and for some projects it can be just that. But for many other projects, especially those that have many humans involved, I really think this is something to consider.

Especially if you find yourself in the situation where you start growing unsure about the versioning process.

Then there is one one thing to do: remove the humans from the process.

Further reading:

• semantic-release docs
• Commitzen docs
• Conventional Commits specification

Is your frontend hogging your users' CPU?

As web frontends get increasingly complex, resource-greedy features demand more and more from the browser. If you’re interested in monitoring and tracking client-side CPU usage, memory usage, and more for all of your users in production, try LogRocket.

LogRocket is like a DVR for web apps, recording everything that happens in your web app or site. Instead of guessing why problems happen, you can aggregate and report on key frontend performance metrics, replay user sessions along with application state, log network requests, and automatically surface all errors.

Modernize how you debug web apps — Start monitoring for free.

The post Unsentimental versioning appeared first on LogRocket Blog.