In any project you start, you should use semantic versioning on your master branch. Semantic versioning is a set of rules you can follow to tag the code of your application in your versioning control software. By following these rules, you will know the current status of your production environment at any moment. Another benefit of using tags in your code is that it allow us to move between versions or do roll backs in an easy and quick way.
Another advantage of having your source code with release tags is that it allows you to work with release branches, allowing you to have better planification and control of the changes you are making to your code.
On semantic versioning, your code is marked with tags with the
vX.Y.Z
form, which means the version of your code. Each piece of your tag means something:
- X (major): An increase in this version number indicates that there are big changes in place; they are important enough to be incompatible with the current version
- Y (minor): An increment in this version number indicates that we are adding new features to our project
- Z (patch): An increment in this version number indicates that we added a patch to your source code
The actualization of the release tag is usually made by the developer who will push code to the production environment. Please remember to update the release tag before the deployment of your code.
Imagine that you start in someone else's project and the master branch is tagged as v1.2.3. Let's look at some examples.
Working on a live project leads to receiving petitions for new features. In this case, we are clearly dealing with an increment of the minor version number because we are adding new code that is not incompatible with the actual base code. In our case, if our master branch is on v1.2.3, the new version tag will be v1.3.0. We have increased the minor version number and also, we reset the patch number because we are adding new code.
On a day-to-day basis you will be fixing bugs in your code. In this case, we are dealing with a small change that the main function is to solve our issue, so we need to increase the patch version. In our example, if the current production version is v1.2.3, the new version tag will be v1.2.4. We only increased the patch number because our fix does not imply other, bigger changes.
Imagine now that we have been asked for a big change to our source code; once we apply our change, some parts of our source will be incompatible with the previous versions. For example, imagine that you are using library_a and we changed to using library_b and they are mutually exclusive. In this case, we are dealing with a very big change that indicates that we need to increase our major version number and also, we need to reset the minor and patch numbers. For example, if our production code is tagged as v1.2.3, the new version code after you apply your changes will be v2.0.0.
As you can see, doing semantic versioning will help you keep your source clean and makes it easier to know which kind of code changes are being done only by looking at the version number.