Software Versioning: a dialogue between Developers and Users
Software versioning
All companies that develop and market software implement a versioning scheme that, in addition to defining and organizing the work of developers, aims to establish a communication between the company and users.
By reviewing the bibliography on the subject, we will find a large volume of information on versioning models and what they imply for developers, but in this article we invite you to reflect on software versioning schemes from the point of view of users.
Initially, as users, what we can get from the software versioning model used by a particular company for a specific software product is information.
- Information on how this company faces the process of developing its software product.
- Information on how it manages the improvements, corrections and changes of the software, and finally
- Information on how often you need to release products, versions or upgrades.
Now, once this information is obtained, what can we do with it?
We can execute, among other activities such as planning system backups, planning download and execution of updates, and defining the processes associated with recovering a stable state in the event of a failure.
The Versioning Problem
Unfortunately, it is common for some users of software to ignore how to interpret the sequence of numbers and letters that we usually call version and from there lose all associated information.
It may actually be difficult to understand a software versioning scheme, as there is no one-size-fits-all model. On the contrary, there are multiple versioning schemes with different precepts and characteristics.
In addition, there is also the aggravating factor that software companies feel free to adapt the versioning models to their own philosophy, introducing concepts such as editing, compilation date, development phase, patches, etc., generating more confusion.
One of the most recurrent confusions is when it focuses on the difference between version, release and update.
Differences between Version, Release and Update
First, when a software company makes changes or improvements to its product, it is generating different versions of the software. Many of these versions are not released to the market, but remain as part of the internal work of the company.
When your company produces a version that you want to release, you then generate a release version that usually includes all the programs involved, as well as the appropriate documentation and supporting materials.
Therefore, all releases are versions, but not all versions are converted to releases.
Having clarified this, we must say that most software producers based on their software versioning model call version those products that arise from radical changes in the system, and release or updates to minor changes or improvements within the same version.
There is some consensus on the reasons that justify a new version, such as:
- Significant changes in the database structure.
- Changes in the platform such as language changes and even a change in the general idea that supports the product.
- Introduce significant new system functions.
- Changes in the communications structure or protocols used.
Whereas the reasons for generating a new release (update) can be:
- Corrections of errors in the code.
- Code optimizations.
- Improved security levels.
- Introduction of new small functions, in terms of aggregation and not substitution.
- Having clarified these terms, let’s review the software versioning model used by Pandora FMS.
Rolling Release
The term Rolling Release, associated with others such as Continuous Update and Continuous Release, refers to a development and versioning model in which the software is constantly updated by small and frequent modifications, which are released as soon as they are tested.
The main virtue of the Rolling Release model is to offer constantly updated software products. This is directly opposed to the fixed time model, also called the standard model.
In the standard model a new version of the software is released after a fixed time, such as six months or five years, for example, this period is an individual decision of each software company.
The standard model, which is still widely used, may have certain negative aspects, such as:
- A very long time between one version and another: the update of a previous version by a new one responds, as we said, to a more or less fixed period.
- Systems can become obsolete: due to the time between one launch and another and the decisions not to update. We have to consider the next cycle in the worst case; as users we usually wait for the launch in the first place. Then wait for the first installers to do their tests, then review all reports of failures or success and finally plan our installation, going so far as to decide not to update, but wait for the next release just to avoid the problems.
- For one reason or another, it is always necessary to reinstall from scratch or clean; that is, those where any previous version must be eradicated.
User Types and Rolling Release
Let’s think for a moment about the users. We can consider two types of users in terms of how to approach the issue of software versioning:
- Those who after installing and getting a stable version of the system look forward to the new versions and constantly want their systems to be updated.
- A second group of users with a natural tendency to install a product reach a stable and functional version and forget about everything “as long as possible”.
For the first type of users the Rolling Release model is perfect, since these users will hardly accept a versioned model that means waiting a specific time for important updates of their system.
For the second group, the Rolling Release model is also convenient because it removes the greatest concern of users, which are failures in a functional system and investment in time and effort in reinstallations.
Thus, both types of users can benefit from the following features of the Rolling Release model:
- Constant updates: The time between an improvement or a change being developed and the time when, as users, we can enjoy that improvement is less than if the standard model were applied.
- No re-installation of the entire system is required: as updates are made constantly and are presented for specific elements. Therefore, we can rule out heavy downloads from the Internet and clean installations from time to time.
Pandora FMS and Rolling Release
Pandora FMS version 1.0 was released in October 2014. From then until version 6, a standard software versioning scheme was used, according to the versions that were released from time to time.
In this link, the reader can check a table with all Pandora FMS versions since its release.
An important milestone was reached in March 2017, when Pandora FMS version 7.0 Next Generation (NG) was released, from which it switches to the Rolling Release continuous release scheme.
The main motivation that led to the introduction of the Rolling Release model in the development of Pandora FMS, as expressed by Sancho Lerena, CEO of Artica ST (developer of Pandora FMS), in an interview with Sourceforge: “...it was the idea of satisfying the needs of users by doing what the software is supposed to do in the best way and also doing new things integrating them to the project that is being executed“.
Of course, the implementation of the Rolling Release model has an impact on the Pandora FMS development process, which starts from the definition of a main repository on which the work of the individual developers is integrated several times a day.
If you want to learn more about Rolling Release and its implementation at the level of development activities, you should read the article on Continuous Liberation published in this blog.
In any case, the application of the Rolling Release model in Pandora FMS offers to the users, besides all the advantages mentioned in the previous section:
- Pandora FMS updates in simple, short and frequent download processes.
- A short time of access to these updates; so short that it can take only a few hours.
- In Pandora FMS specific and incremental updates are generated that allow to impact only on what is out-dated or on new services.
On the other hand, we must say that the defenders of the standard model use as their main argument the stability of the model, starting from the fact that all changes and improvements are tested in an integral way with the whole system before releasing the version.
It should be noted here that faults associated with the functionality of the entire system could be controlled by applying sufficient tests with the correct methodology. In fact, for Pandora FMS, throughout 2017, many updates and enhancements were released without any major flaws or problems.
To finish this off, we invite you to continue investigating about the facilities that Pandora FMS offers to facilitate the download activities and implementation of updates in this link.
And if you still don’t know all the advantages that make Pandora FMS Enterprise the most complete monitoring solution, we invite you to check this link.
