What is Semantic Versioning?
Major versions of the software are assigned unique version names or numbers that works as control over the release. The numbering is usually incremental within a version category for new developments in the software. It lets you keep track of what was released and when.
The Semantic Versioning (SemVer) allows us to track computer software using different software versioning. The internal version number may change more frequently than the released versions for other users.
Developers mention semantic versions in the published packages for the team to know the code status, stage, the rule applied, and the version.
E.g. First release, new product 1.0.0 and bug fixes or patch release will increment only the third digit 1.0.1. Minor release with new features will change only the second digit i.e. 1.1.0 and major release will change the first digit and all other digits to 0 i.e. 2.0.0
The version can start as 0.1.0 but not as 0.0.1 as it is the first release and not bug fixation.
Why is Semantic Versioning important?
With ongoing changes, every software product goes through the stage, bug fix clarity, and new features release. The applications that
Versioning our apps helps us keep track of what’s been added/removed at what point. It can get real hectic, real fast, especially in the early stages when you’re releasing new features and fixing bugs. You may prefer to reference things that have been added or things that have been fixed.
The major version number is necessary for end-users to know the new features they can expect.
Advantages of Semantic Versioning:
- Track phases and transition in software development.
- It is self-explanatory of the changes in the software.
- Keep the log of updates and refer when needed.
- Handle project dependencies efficiently with a proper channel of information through versioning.
- Maintain the uniqueness of numbering and ease the automation of versioning.
- Pattern used in versioning is the rule all developers need to follow for smooth communication and better understanding. Semantic versioning affects both the internal and external users.
- Identify the sequence and each sequence has a meaning that can highlight its attributes. Sequences typically separated with special characters like dash, forward slash, hyphen, can be used singly or different combinations.
- Classify the change with the significance it carries.
- Compatibility between two versions can also be a method for versioning.
- Keep the logs clean and documents well maintained.
Release and Risks:
- Major releases contain the considerable amount of features and it is possible to avail changes by running updates. It would not require developer’s assistance. It involves more risks due to impact on multiple users and not just the developers. You can even reset the major versions once the defined development is complete and new phase begins.
- Minor releases have trivial changes that do not create a need for support from the developers. These are mainly some internal releases and such changes are clubbed for the new release in a major version for public use. It has a lesser risk compared to major releases as this release has few updates and the apps can work without being updated.
- Patch releases have the least risks as the improvements in current development are for the features that already exist. Here again, the developer assistance is not required.
Release Frequency:
You can plan the release frequency of the major release say every 6 months, each of it may include 1 or many minor releases and usually patches are released on a weekly basis.
The release frequency can be part of numbering for active and previous releases.
Points to Ponder:
Simplify the Semantic Versioning by defining internal and external versions, its names, and numbers or when to use version change. Designate the development stage for deployment and testing related releases.
If you are using numbers for versions and this is your second release with a minor release 3, then you are using 2.3.0 but in the future when you fix some bugs update it to 2.3.1.
For public release, you can use the same numbering or to reduce the URL size you can share it as 2.4.
Internal versions are the work in progress tags that continue to remain from the start of the project, an added feature, and bug fix until the first release. Initial numbering would look as 0.0.0-wip.1 then 0.0.0-wip.2, after the first minor release it is 0.1.0-rc. Again, after the bug fixes the third digit only will change 0.1.0-wip.3 once the minor release is confirmed the version will be 0.1.1. As we progress towards the major release, the minor releases and the fixes are rolled up to higher version. The first major release version would be 1.0.0 preferably written as 1.
Resetting version is a strategy used when the selective target of the development phase achieved in parts of minor releases and patches. Then semantic versioning is reset to the new development phase numbered as 1.0.0.
The tag names of the version used over public space are v along with the semantic versioning. E.g. if the release version is 2.4.3 the display will be v2.4.3, here the semantic version is 2.4.3. for major release 2, a minor release is 4, and patch number 3.
How Semantic Versioning is used?
- API Semantic Versioning: The URL of your API need not have the complete version number, as the patches can be just internal. You should update the API every time there is a new release as this is a major change thus the version is important. Similarly, you can number the databases and flow charts
- Angular Semantic Versioning: Angular framework and its releases have version numbers with three parts major.minor.patch.
The versioning should be limited to three digits to avoid complications and ease of handling projects. Based on the number of users one should deal with the semantic versioning. Be cautious about what your users see and whether the same version is available to them.
Disciplined actions for semantic versioning have a capability to hint the similarity and uniqueness of the releases. Convey the versions with an intention to serve better not complicate. Decisions we make have greater impact than we think.
