Semantic versioning refers to a system that assists code developers, project managers and clients to grasp the general release process. Semantic versioning consists of some pointers so that we can have a better understanding of what’s going on in a release.
Example: a version figure 1.23.4 with associated labels e..g minor, major and patch versions.
If you dig this further, you will find the majority of major works that employ Semantic Versioning on GitHub.
Major Variation
When we execute this variation, it implies the existence of backwards-unmatched shifts in this release. The Application Programming Interface (API) has shifted and may include breaking adjustments for API users. Re-adjust both minor and patch variations once the key number has been increased.
For example, if we applied a major release version for figure 1.23.11 it would change to 2.0.0.
Minor Variation
We increase the minor variation when introducing new attributes or functional features that do not split or shift the current API. When you attempt to increment the minor variation, re-adjust the patch version to “0”.
Apply the minor variation when you are executing non-breaking tweaks that aren’t bug fixes.
If we applied a minor release to change the figure 1.23.11 the new figure would be 1.24.0.
Patch Variation
The Patch version is applied to fix bugs. There are no functionality edits in the updates. There is no need to re-adjust any other numbers and the numbers are limitless. For example, if we were executing a patch release for figure 1.23.11, the new figure would be 1.23.12.
Pre-releases & Development
We won’t attempt to explain this language in-depth as there are several ways to execute it and guarantee an article of its own, but it’s important to consider pre-releases and how to read them. This knowledge is useful when we want to launch software unofficially to a portion of users for testing aims.
Pre-released may not be fixed or match the latest major, minor, or patch variations that they suggest.
Example: “1.23.11-beta”. Here our pre-launch identifier consists of two components. The “version 1” and the “beta” tag. You may also view some developed data affixed as well such as the origin commit form of the development.
For more info, we have included a couple of useful links below to some great reports that will enhance your understanding of pre-release tagging.
Leave a Comment