When you are developing your projects following DevOps methods, you know that one of the main goal is to automate as many processes as you can. By using conventional commits and semantic versioning, you can automate the version upgrades and release notes! Let’s see how it works.
What is semantic versioning?
Semantic versioning is quite easy to understand. Actually, you might be already doing something similar in your projects! It’s a specific way to declare the versions of your apps.
What are the benefits for your project teams?
By using semantic versioning, you ensure all your versions have a real meaning and interest for your user. It also improves the communication within a team’s project and with potential contributors!
How does it work?
When you’re using semantic versioning, your version are composed of 3 main information, written X.Y.Z.
X corresponds to the major changes, the ones which are not backward compatible with your software. Y corresponds to minor changes, the ones which bring enhancements and are backward compatible. The Z corresponds to patch, bug fixes not affecting the software. It corresponds to fixes that won’t introduce breaking changes nor add new features to the software, but adjust an incorrect behavior. Those three letters are symbolized by numbers, increasing for each modification.
There are some rules you need to follow when using semantic versioning:
- All your development versions need to contain a major, minor and patch numbers.
- All numbers can only increase. Patch and minors start at 0, and major usually starts at 1 (otherwise we talk about beta and alpha releases).
- When a minor version is released, patch numbers goes back to 0.
For example: 3.2.1 – 3.2.2 – 3.3.0 – 3.3.1
- The same rule applies to minor and patch numbers when a major version is released.
For example: 3.2.1 – 3.2.2 – 3.3.0 – 3.3.1 – 4.0.0 – 4.0.1
- Once a package has been released, the version can’t be modified.
What are conventional commits?
Conventional commits are used in your git flow. When you are working in your branch, and you want your colleague to do a review of your commit, it’s easier for him to understand what happened in these commits if your commit history is clear!
What are the benefits for your project teams?
Using conventional commits in team projects, all the team members will write their commit message the same way. The communication within the team will be improved! Furthermore, it works the same with contribution: it’s a lot easier for someone arriving in your project to understand what you worked on.
Finally, once you’re using conventional commits, you can automatically generate your project’s release notes, as well as your semantic versioning.
How to build it?
There are several ways to build your commits. We will present you here the V1.0.0 of conventional commits! Following those steps, you’ll add important content to your commit description, it will give meaningful information to the rest of the team.
If you choose to respect this convention, you will write your commit messages like this:
<type>[optional scope]: <description>
The type corresponds to the action that has been made in the commit. Usually, you find here fix: or feat: (for feature). But of course, other types are allowed, such as build:, chore:, ci:, docs:, style:, refactor:, perf:, or test:. Those types are just a basis, and you can create as many types as you need to fit your projects needs.
When using conventional commits, the type you will add in your commit will give context to your information. Fix: will refers to a patch level in semantic versioning. Feat: will indicate a minor level in semantic versioning.
Then, you can put an exclamation mark (!) right after scope, symbolizing a major change for the semantic versioning. The title Breaking changes in the footer can emphasize it.
Regarding the scope, you can use it to add information about the feature that will be affected by the changes. Finally, you can use description to add more data. Off course, it shouldn’t repeat the scope or the type!
How combining both systems?
To combine semantic releases and conventional commits, you can use a specific tool that will link them automatically. At Go2Scale, we use the job Semantic Release!
You can include this job in your CI/CD pipeline with one line of code. Once it’s done, this job will create a new version of your application or development each time the pipeline will be triggered.
Why combining conventional commit and semantic versioning?
Those two practices combined are a real improvement for your CI/CD processes. You will incorporate all the benefits of both parts in your development, and automate the versioning and the changelogs creation without adding work, only procedures!