Are still you bumping the version of a package manually?
If the answer is yes, this post will help you and your team to save time and conflicts so you can focus on making your product the best product ever made.

In this post I’ll explain what is Semantic release and how you implement it in your project.

Semantic versioning

Before we can talk about Semantic release, we must talk about Semantic versioning which is concept where:

• Each package has version which is composed from 3 parts - major, minor and build.

• When committing a change to a package we need bump by one of the parts based on the following rules:

  • Major - When breaking a public API. For example removal of a mandatory argument of a method.

  • Minor - When adding a new feature. For example, adding a new API call.

  • Build - When fixing a bug.

• Each bump is made manually.

From my experience after implementing Semantic versioning you might face two issues:

• You forget to bump version in your PR(If your CI doesn’t do any checks) which will force you to merge another PR if you found it quickly or in the worst case will override existing package with the new code.

• Merge Conflict - This is very common in large scale repos where multiple develops might commit changes to same package and after one merges its changes, others will have to face merge conflicts when merging new changes.
  It’s more inconvenient more then an issue, but still is affects life quality of a developer.

To overcome those issues we have Semantic release which is the automation process of bumping a version for a package.

How does it work?

To implement Semantic release we need to do two things:

• Agreeing on conventions of commit message which tells what change was made in a package. Based on the message we can determine which part the version to bump. You can find here examples for commit message

  This is the critical part, because you must collaborate with your engineers.
  Without this part the next part is worthless.

• Run a CI job which reads commit's message and bumps the version relevant package based on the message.

How to implement?

As we discussed, after agreeing on conventions we need to write a CI job.

The job must run only on the branch from which you’ll start the deployment process.
The job needs to scan the commits which were merged and based on the commit message will know which package to bump and which part the version needs to be bumped.
Each language has it own bump version utility which will do the work for you.
Some of tools will help you to configure your CI/CD properly.
The final step is to commit the changes and push it.

Epilogue

We learned how we can automate a daily small action which might lead to fatal issues in case we don’t do it properly.

If you've reached so far, I want to thank you for reading the post!
Join me for the next posts about DevOps where I'll share with you my experience and thoughts.
Let me know what do you think about the post and which things should be improved.
You more than welcome to contact me on LinkedIn and on X(Twitter).