Sooner or later all developers need to handle some sort of versioning their software. If you've been there you know that manual updating versions, changelogs, and tags are prone to error and emotional decisions.

In this article, I'll try to show an easy and automated way of managing your versions following the conventional commiting structure and with the help of standard-version.

Install standard-version

Let us start with installing our package

npm i standard-version -D

Now, for the purpose of easiness add the following script to your package.json

{
  "scripts": {
    "release": "standard-version"
  }
}

How it works

Our package needs us to follow the Conventional Commits Rules in the repository. This means that we must use the correct syntax.

Here is an overview of how it's done:

1. fix for a PATCH
2. feat for a MINOR 
3. ! scope suffix for a MAJOR 

So the commits must follow the pattern scope!: message the ! is optional for a MAJOR.

feat: new reset password button` -> 0.1.0
feat!: new reset password button` -> 1.0.0

Workflow

Now that all is configured and we've understood the ground rules for automated versioning, let's have a look at a simplistic view of how a workflow should be.

Developing a feature on a feature branch

1. git add .
2. git commit -m "feat: created a reset password"
3. git push

Merging to the master branch - this is where the magic happens

1. git merge origin/feature-branch
2. npm run standard-version - the package is looking into the commit history and automatically increasing your API version to X.Y.Z
3. git push —follow-tags origin master - this is pushing your bumped with the changelog file and tags generated

And that's all! You should be able to see on your master branch the corresponding bumped version with the changelog file and all linked to a tag.

Common mistake

According the semver

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

This means that until you intentionally run npm run release -- --release-as major you won't see your major version bumping from 0.y.z to 1.y.z. From this moment on, the package will do its job and bump major versions as well.

Conclusion

Bumping versions based on conventional commiting convention of rules is seen as a good practice in order to have an explicit commit history.
With the help of standard-version we've seen above we are able to automatically bump versions and track changes each time an artifact is released into production.

Special thanks to https://unsplash.com/@csoref for the header image :)