Semver Procedure
Semver Procedure[edit]
SemVer is a 3-component system in the format of x.y.z where:
x stands for a major version
y stands for a minor version
z stands for a patch
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
1. Start at Version 0.1.0
The initial development of a project starts from a single feature. It must be taged as 0.1.0.
2. Version before 1.0.0 is development
Only after reaching version 1.0.0, the first release of a project must take place. Everything before it is considered as development phase.
3. Code Name
Version number must be assigned only after completion of development work. During the development, the version will be identified using a code name. The code names is used only for identification during the development phase and will not be used after a version number has been assigned.
4. Release candidate
After all the features for a particular release has been developed, it must be taged as a release candidate. No new features must be added to it. Only bug fix must be done. The release candidate must be deployed to sandbox and all the testing must be done. Only after fixing all the bugs and getting confirmation the version must be considered for release.
5. Release
After getting confirmation for release it must be taged with the proper version number and deployed to live. 6. Hotfix
If any bug is identified in live, the bugfix must be done in the deployed version and on confirmation must be deployed to live. After bugfix the patch number must be incremented.
7. Version increment
When a new feature is released and minor version is incremented the patch is reset to zero. When a major release not compatible with previous version is deployed, the major version number is incremented and both mino and patch is reset to zero.