We at DHTMLX have been delivering a range of complex JavaScript components for many years. And just like any responsible software vendor, we do not forget to add unique version names (numbers) to each new update of any DHTMLX product. That is where software versioning schemes come into play. They serve as a way to identify various product releases and updates, thereby making them easily trackable by software providers as well as end-users.
In this article, we’ll share with you how the use of a popular versioning scheme helps DHTMLX in organizing internal processes and review two most popular schemes in more detail.
What Are Versioning Schemes and Why They Matter
A versioning scheme is a practice of categorizing changes in a software product during its lifecycle. To put it simply, these are unique identifiers containing numbers (or letters) given to different software iterations.
So why the use of versioning schemes is important? The short answer to this question is the clarity that such schemes bring into communicating software releases and updates. They serve as a vital source of information for members of our development teams, technical support specialists, and especially end-users.
Let us prove the relevance of versioning schemes using the example of DHTMLX. In our development processes, we stick to one of the most widely-used versioning strategies, namely semantic versioning (SemVer).
Versioning allows our dev teams to facilitate Continuous Integration and Continuous Deployment (CI/CD). Every time a new version of DHTMLX widget is pushed to the repository, automated pipelines build, test, and deploy the library bundle. It helps to ensure that the release process is simple, automated and reliable. Versioning is a cornerstone of this process.
The use of Semantic Versioning also plays an important role in dependency management. Version numbers in SemVer give helpful insights into backward compatibility for our programmers as well as for our customers. Our dev teams use some shared code libraries for building UI components and SemVer helps us to avoid dependency issues (such as “dependency hell”). And it is also true for our customers, who use the info on backward compatibility when using our UI components in their apps.
Testing teams can pinpoint regressions or bugs to a particular version of the library. This narrows down the scope of what they need to examine, making the troubleshooting process more efficient. Additionally, each issue that is registered in our internal bug tracker has fields for the earliest version of the product where the issue can be reproduced, all affected versions, and a fix version. We use this info to advise our users in updating the library as soon as the fix is available.
Specialists of the DHTMLX support team also benefit from software versioning when handling various technical issues faced by members of our substantial user community. For instance, it may happen that users who run older versions of our products may complain about the issues that are already fixed in newer versions. It is much easier for support personnel to verify errors if the product version is known.
And finally, it is crucial for our customers to be aware of any updates that take place in our products since they are used for implementing core functionalities in web apps. Version numbers give users an idea of what a particular update brings in terms of functional capabilities and code compatibility.
Each DHTMLX customer can download any previous version of the purchased product from a special archive in the Client’s Area.
Overview of Top Versioning Schemes
Now it is time to discuss specific examples of versioning schemes and their peculiarities. There are plenty of known software versioning schemes that can be used by vendors for distinguishing between earlier and later versions of the same product. But we’ll focus on two most popular approaches to assigning version numbers: Semantic Versioning and Calendar Versioning.
- Semantic Versioning (SemVer)
Introduced by Tom Preston-Werner in 2013, this versioning scheme quickly gained popularity in open-source as well as commercial projects. As mentioned above, the DHTMLX team also prefers this versioning pattern since it is quite informative and fits well with our development workflow. This scheme proposes a simple set of rules for how software version numbers are assigned and incremented. When using SemVer, software versions are usually named with three non-negative numbers separated by dots.
With SemVer, the version number may include additional labels for a pre-release version (e.g.1.0.0-alpha) and build metadata (e.g. 1.0.0-alpha+001). They are available as extensions to the MAJOR.MINOR.PATCH format. Such labels are optional and are not widely used. Some businesses also prefer to use a simplified form of the SemVer scheme without the PATCH part.
- Calendar Versioning (CalVer)
Calendar versioning has a long history, but CalVer itself was introduced in 2016. It is a popular alternative to the SemVar option. CalVer is promoted as a good choice for time-sensitive projects with a large or constantly-changing scope. This scheme relies on the project’s release calendar for generating unique version identifiers.
In contrast to SemVer, CalVer doesn’t give you explicit information about API changes or compatibility between versions. But on the other side, this scheme allows you to quickly get answers on time-related questions: how “fresh” a release is, how long it is maintained and supported, and how much time has passed between releases. This versioning convention is currently used in multiple known projects such as Ubuntu, Twisted, Pip, etc.
Conclusion
As you can judge from the experience of DHTMLX, the use of a proper versioning scheme can be a true asset for software vendors. Such schemes help to ensure productive communication and collaboration among developers, users, and other stakeholders. In this article, we considered just two of the most popular schemes, but there are other lesser-known options such as ZeroVer (0-based versioning) or Hash versioning. However, you don’t have to adhere to any specific versioning scheme if it does not fully meet your requirements. In such cases, it is common to come up with your own technique for issuing version numbers or combine the existing ones.