Semantic Release Automation - Part 1 - Understanding Semantic Version
Tags: javascript, devops, npm, webdev
Published: 2019-09-26 20:41:34

Have you ever wondered why any software package must have a version number? what is the difference between this version `1.0.0` number to this one `1.1.0`?


## Table Of Contents
* [Motivation](#motivation)
* [What Is Semantic Versioning](#what-is-semantic-versioning)
* [Updating Your Package Version](#updating-your-package-version)
* [About Semantic Release Package](#about-semantic-release-package)


#Motivation <a name="motivation"></a> 
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/zgqmi0ug88q4j4qpf5ww.png)
In javascript world, we have multiple package managers such as [npm](https://www.npmjs.com) and [yarn](https://yarnpkg.com/lang/en/) that handle your dependencies in your application. They provide a bunch of features to make your life easier, you can view these features on their websites.


With each package you installed in your application, there is a version number on each one of them. 

#What Is Semantic Versioning <a name="what-is-semantic-versioning"></a> 
[Semantic versioning](https://semver.org/) is a set of rules that dictate how version numbers are assigned and incremented. The image below describes what each number means:

![Semantic Versioning](https://thepracticaldev.s3.amazonaws.com/i/mfyaefad6784i9z4ll2c.png)

So if: 
- The **first number** from the right is incremented (patch). It means that there is a new **hotfix/bugfix** on this package.
- The **middle number** is incremented (minor). It means that there is a new **feature**.
- The **last number** from the left is incremented (major). It means that there is a **breaking change**.


It is important to highlight that it should be safe to update the package if there are any patch/minor changes (backward compatibility). If you find any major change, you have to double-check the package's release notes before upgrading its version. 

#Updating Your Package Version <a name="updating-your-package-version"></a> 

There are two ways to update your package version, either to do it manually or by using [npm commands](https://docs.npmjs.com/cli/version) or [yarn commands](https://yarnpkg.com/lang/en/docs/cli/version/). If you don't have any package yet you can create a new one by running this command:

```bat
npm init
```
or
```bat
yarn init
```

Assuming that the current version of your package.json is `1.0.0`. If you run this command 
```bat
npm version patch //1.0.1
```

This will update your package.json version and it will be set to `1.0.1`.What is happened under the hood is **npm** will read your `package.json` version and will update its value. You may also like to try out these commands and see the results
```bat
npm version minor //1.1.0
```
```bat
npm version major //2.0.0
```

so whenever you have done with your feature/bugfix or any other change you can use run these commands to update your package version. but there is a problem here, what if we are working within a team and each one of them will run these commands, what is the final version? how to avoid this conflict? even if you are working alone, trust me life is too short to run these commands every time after finishing your stuff.

#About Semantic Release Package <a name="about-semantic-release-package"></a> 

[semantic release](https://github.com/semantic-release/semantic-release) package is designed to automate your releases with many features like:
- Create and update **CHANGELOG** file
- Publish your packages to any registry.
- Update package.json version.
- Integration with any continues integration tool.
- Integration with GIT Hosted services.

In my next article, I am going to explain how to set up this package in your project and automate your workflow.