You might have come across version numbers for your Operating System, apps or software tools that you use, and more. Understanding version numbering might not be as complicated, but it is not quite simple either. So, let’s find out all that you need to know about how software versioning works in Vivaldi.
What are version numbers?
The version number is ubiquitous in Software. All applications have one, but how they are defined and updated varies. One can even argue that a lot of hardware has version numbers, too, such as CPUs, phones, and cars.
The most simple of version numbers are the single numbers: 1, 2,3, etc., and that works fine … until you need to release a bug fix version. Then you add a second number, called a “minor version” (with the first called a “major version”), making it 1.0, 1.1, 1.2, etc., and once you make a lot of builds with small variations, you start adding a third and then a fourth version number, which can depend on how your process works.
Superstition related to numbers among users. Really?
There is a bit of caution or superstition among users about the .0 minor version number. The reason for this is that these versions tend to have major changes that turn out to have not been fully tested and can occasionally cause major problems for the first users to install the new version. This can happen for any first version after a relatively long development cycle, so don’t blame the “0”, when it might just as easily happen with the “.9” minor version.
Sometimes, people choose a different version number system. The oddest one (and, in a way, perfect one) I have heard of is the TeX typesetting software written by (computing luminaire) Donald Knuth. He chose to use more and more digits of the number π (pi) as the software became more and more “perfect”, the current version is 3.141592653.
Some vendors, for example, the Linux distros, use a numbering system where odd-numbered major versions are more unstable because they are developed more extensively and intended for testers, while the even-numbered ones are not updated that extensively, and are more stable, and intended for normal users.
A recent move among some software vendors has been to increment the major version number, for each release, never incrementing the minor number, and just incrementing the fourth number when updating for minor versions. Two of the major users of this system are Mozilla and Chromium.
Strictly speaking, a version number is just a way of separating versions of a product from each other, and the actual sequence of numbers often makes no difference in an engineering sense (although, for interoperability with other software, version numbers do have significant meaning).
What’s in version code names, anyway?
Some vendors also use various code names for their versions either internally (which Microsoft did for several Windows versions), or as branding, which has been used by Apple MacOS and several Linux distro vendors.
Code names can be cute, but I don’t really like them, since they make it difficult for those unfamiliar with the product to tell which was the old one, and which is the newer one when you are looking for a specific version, and everybody only talks about FunnyName and FancyName, and you have no idea which version either of them are referring to.
Version number format in Vivaldi
In Vivaldi, we have a version consisting of 4 numbers, major, minor, nightly, and the build. E.g. the current Vivaldi version is 6.2.3105.54
- The major and minor numbers
The major and minor numbers, in this case, 6 and 2 respectively, remain the same for a given version cycle, and we generally only increment the minor version for each Chromium version we update to (in version 6.2 that is Chromium 116). We only increment the major version when we release major features (or we feel like we have stayed on a number too long).
If we decide to increment the major version, our normal procedure is to make that change just before the Final release, usually when we start releasing Release Candidates (RCs). At that time, the nightly version number is also updated.
2. The “nightly” number
The third number is called the “nightly” number, because it is incremented automatically every night on our “main” development branch, assuming there have been any code updates since the previous update of the number. The number 3105 shown above, means that the have been close to 3100 nightly updates of the number. Well, almost.
As mentioned below, we do occasionally increment manually, and early on (10 years ago) there was a bug in the update script that meant it incremented double each time.
This number allows us to more easily track when changes happen, especially when there is a bug we need to track down. This number gets added as a “tag” in our source repository, so it makes it very easy to go back to a given timeslice and look for relevant changes (a process called “bisection”, which works by picking a change in the middle of the timeslice, then testing if the problem is present or not, and repeat in the section including the problem, that can be partly automated). This process can be relatively quick (if you ignore build time), as a timeslice involving 1000 code updates can be tested in about 10 steps.
Sometimes we change the “nightly” number manually, the most common reason is that a new Chromium version has been integrated, but we have also done so when we prepare to release a major version update, e.g. 6.0, so that we don’t have the same nightly for two different major/minor versions. There is nothing wrong with keeping the number, but it keeps better track of the actual changes.
Those following our snapshot channel closely will see that we use the nightly number as one of the identificators in the announcement and that for several weeks it keeps incrementing, and then “suddenly” stops incrementing. This happens when we start stabilizing the code before a release, and we do that by creating a source code “branch” to which only vetted code updates are added. This process isolates the next release from the hustle and bustle going on in the “main” development branch and also allows developers to prepare major changes to start testing them more widely, without affecting the upcoming release.
Usually, the Desktop and Android versions branch off at different times, which means that they have different nightly version numbers, but Vivaldi 6.1 was an exception when both versions branched off on the same day. This actually had an odd effect as we will see below.
3. The build number
The fourth number in the Vivaldi version number is the build number, and it starts at 1 again each time the major, minor, and/or nightly number changes. It lets us distinguish different builds of Vivaldi. On a normal day the number can go up to 15 or 20, but can go a bit higher on days with many code updates (we try to generate a new build every time the code changes, although usually there is more than one code change in a given build because we don’t have enough machines to build for every change, so they get bundled).
When we start stabilizing the release the number will start going higher, the above one was 54, and it will get higher as we release more builds. The build number is not just incremented when we add a new code change, the number is also incremented when we start different kinds of builds.
Our build system has several configured build types:
- The internal development builds, which we try to get for each code change
- The Desktop Nightly Builds, which are generally started each night (if there are updates since the last build), and are used in the snapshots
- The Mobile Nightly, also started each night and is the basis for the Mobile snapshots
- The builds for various car manufacturers, e.g. Polestar and Renault, which also have Nightlies or Weekly builds
Additionally, there are such configurations for each final version, e.g. for version 6.2, when we start stabilizing for final release.
When a build for each of these build configurations starts, the build gets assigned a new version number that is unique for that configuration.
For the stabilization branches, in particular the Android one, with several product lines, this means that the build numbers can increase rapidly as we start new builds for the snapshots and releases. A particular case of this was seen for 6.1 since both Desktop and Android had the same nightly number, so we had a desktop release build with a build number of 300!
4. Even larger numbers
There is a second range of build numbers, too. Developers frequently need to test their code changes before applying them to the main code base, to (hopefully) make sure nothing breaks. These builds get build version numbers assigned from a different pool of numbers, which started at 10000 (10 years ago), and have been increasing for every test build since, and has now passed 38000. These builds are (almost) never released as snapshots, although we have done so in a few special cases.
Oops! We make mistakes.
Occasionally, mistakes happen. One was mentioned above when we accidentally incremented the nightly version double. Another one happened recently, leading up to the recent iOS release. The standard procedure for updating the Vivaldi version number is that the minor version number is incremented around the time the desktop stable is released, which is what happened when the 6.2 version was released, and the new 6.3 version was designated.
However, we were going to be releasing the iOS version, and it was using the 6.3 version, but it is still based on Chromium 116, NOT the upcoming Chromium 118 (which was integrated recently). One thing we absolutely don’t want to do is mix two different Chromium versions in Final releases of the same major/minor version.
Oops! So, this landed us in a small pickle when we noticed the issue. We eventually landed on a “hacky” solution: We released the Vivaldi browser on iOS as version 6.3, then incremented the version to 6.4 after Chromium 118 was integrated, and the next desktop and Mobile releases will be called 6.4 (so there will be no Vivaldi 6.3 Desktop/Android releases!).
As you can see, there are a lot of things that go into creating a version number.
PS: The published version of this article is its fourth version! 😆
