When the development scope is being incremented, the complexity of development, Testing & Releases would be more complicated in Continuous Integration & Continuous Delivery pipelines. Downloading dependencies in software packages, and versioning is even more complicated of frequent releases if there is no well defined mechanism. Semantic versioning is one of the solution for reduce this complicated hassle.
Version is more important to developers to track their historical tracking, it gives a well defined versions of software releases. Therefor it adds more befits to the software development as well as CI/CD pipelines.
Benefits of Semantic Versioning
- Historical tracking of code development.
At any point developers can get the idea of code status from any historical point. - Universal builds packages are available to anytime deployment.
Build can be triggered from any of previous tags, and it includes all the required dependency and other configurations. Therefor those tags can be easily used for build project deliverable as required from history. - Easily identify the code changes including API, functional and bug fixes.
- Helps to manage releases and code development.
Semantic Versioning Format
There are three Major parts are in semantic versioning, Major, Minor & Patch.
- Patch : Patch is where the developers change code to bug fixes after production deployment. This part is only changed when other major & minor are remained as it is. And this change should be backward compatible Please take a look on below example.
v1.3.4 //before bugfix v1.3.5 //after bugfix
- Minor : minor part also a backward compatible changed in functional requirements. When there is a feature development for a release, which is versioned with minor part of the version number, and this feature should be backward compatible. Below example shows the feature development versions.
v1.3.5 // before feature development v1.4.0 //new feature development
- Major : Major version defines about a massive change with backward incompatible of code change. That may a API change, architectural change or related changes.
In such a major version is released, it cannot be revert back to a previous version since there a backward incompatible changes.v1.4.0 // before major change v2.0.0 // after major change
There are some several basic rules that everyone adopts in the semantic versioning.
- Initial development should start with v0.1.0
- When you want to release as first release from the project, it should be changed to v1.x.x
Best practice of versioning is very convenient way of improving software delivery cycles including CI/CD. Since most of the companies are adopting with DevOps and Agile practices, best practice of versioning is most important.
disamTECHbench 