Version

What is a "Version" in a Program?

The term version has multiple meanings when we use it to talk about software, be it utility programs, applications, or even operating systems. In general, it means that there are various different programs that are called by the same name, and we can only distinguish them by their "version." For example, take Inkscape, which is an application. If we update Inkscape, that means we changed the programming of Inkscape, therefore, it's no longer the same program as it was before. The program before the update and after are different. We have two different programs. And they're both called Inkscape. How do we differentiate between one program and another if they're called the same? For that, we use versions. There are many different types of "versions," such as:

1. The current version of a program, compared to past and future versions: this type of version identifies that changes were made and accumulated in a program after updates, fixing bugs, adding features, and so on. In this case, we'll generally see a version number tuple code such as 1.9.4. We'll learn about how this works below.
2. The alpha, beta, release candidate, and release version: these refer to different versions in the development cycle of a new version.
3. The portable and installer version of a program: in this case, we're talking about multiple different ways to package the same application. Sometimes, an error only occurs in the portable version, for example, and can't be reproduced in the installer version.
4. The Windows and Linux version of a program: in this case, we have a program that is cross-platform, it can run in multiple operating systems. Sometimes, a bug only affects one operating system, and can't be reproduced in another.
5. The free, trial, premium, "pro," or enterprise version of the program: in this case, we have a program that has limited features in its cheapest or free version, and has more features accessible only in a higher paying tier.
6. The 32-bit and 64-bit version, or x86 and x64: this refers to CPU architecture. Nowadays, CPUs are 64-bit, so you don't see many 32-bit versions anymore.

One example is Windows: Windows is released in two versions, called Home and Pro "editions," with differing features. The names of some Windows version are: Windows 95, Windows 98, Windows ME (Millenium Edition), Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10 (there is no 9), and Windows 11.

How Version Numbers Work?

You may have noticed many applications come with a version number such as 1.9.4, or 0.1, or 7.4b, or 7.4rc, or something like that.

In many cases, these numbers don't really mean anything, except that higher numbers are more recent. That's because many developers don't really know what to do with them, so they just make bump up the version every time they release a new update. However, in well-organized applications, you may see something called semantic versioning being used, where each version is a tuple of 3 numbers in the format major.minor.patch. The idea is that it should work like this:

1. A major version change is not backwards compatible.
2. A minor version change is a backwards compatible feature addition.
3. A patch is a bug fix that doesn't add new features.

Let's understand what this means.

Essentially, if we're on version 1.0.0 today, and tomorrow a new version comes out, that version could be ANY of the following three:

1. 1.0.1 - a bug from yesterday's version was fixed.
2. 1.1.0 - a new featured was added in just one single day. Amazing.
3. 2.0.0 - we immediately broke backwards compatibility.

Until a new feature is added or backwards compatibility is broken, the patch number can go up indefinitely.

For example, if we never add a new feature and never break compatibility, we could have 1.0.9999 after releasing 9999 versions.

Note that THE WAY IT DOESN'T WORK is that 1.0.9 becomes 1.1.0. That's just not how it is! After 1.0.9, we can have 1.0.10. Similarly, after 1.9.3, we can have 1.10.0.

Backwards Compatibility and Instability

In general, the version with higher patch is the most stable one. Every time a new feature is introduced (in a minor version), with it comes bugs that nobody has found, reported, or fixed yet. So it's possible for 1.1.0 to be less stable than 1.0.9, for example. Once bugs are fixed, it becomes the better version again.

That's why updating to the newest version all the time can backfire. You'll always be using the programs that have been the least tested. On the other hand, the more stable versions tend to lack newer features. One such case are long-term support versions, also called LTS. These tend to only get fixes, and no more features.

Backwards compatibility is the concept that something made in a previous version will work in the new version. In general, it's a good thing since breaking backwards compatibility means everything that depends on it must be updated. On the other hand, maintaining backwards compatibility can make projects extremely complex, which makes it difficult to add new features. A middle ground is deprecating features: when a feature is deprecated by the developer, that means it won't be available anymore in the future, and they're giving you some time to update your use of the software before that feature is removed completely.

For example, let's say an application can save project files. Its project files will be designed in one way. However, after 5 years, the application has a lot of completely different features, and everything works in a completely different way. Would it be able to open project files created in old versions?

Typically, applications will save in the project file which version of the application was used to save that file, and create an algorithm to automatically migrate the file to the format of the current version when it's opened. If the format of the file has changed several times through the years, this may become exceedingly complicated. Note that some applications have been in development for decades. You may end up in a situation where you can't open old files in a new version of the application.

In this case, you can generally find a way to upgrade the old file to an older version that is more recent than the version the file was saved with, and progressively upgrade it until the current version, but that's not a process that may work every time.

Special Cases

Some projects may use a variant of the semantic versioning system where some versions have special meanings. For example, in Node, odd numbers are considered unstable, and even numbers are stable, so Node 18 is stable, but Node 19 is not.

In particular, GIMP's official public version currently is 2.10, and it has been that version for ages. Most of its work has been being done in a "special" version 2.99. That's because an important of an important part the project uses, the GTK toolkit. GTK is currently in its 4th major version, but GIMP still uses GTK 2. In order to properly upgrade to GTK 3, it needs to make sure all of its current features work with GTK 3. Otherwise GIMP 3.0 would have less features than GIMP 2.10. GIMP chose to do this by selecting a "special" version, 2.99, and using that version to release its incomplete, non-backwards-compatible improvements.

Alpha, Beta, RC, Release

In some cases, a version can be considered an alpha, beta, or release candidate version. They get suffixed with the letters "a," "b," and "rc," respectively.

An alpha version is a majorly untested version that contains only a rough draft of the features.

After that, the beta version has something intended for end-users, but that may have critical bugs, such as bugs that lead to data loss. Typically only a few users involved with the development of the project, called beta testers, use this version.

A release candidate is a version more open to the public which the developer at least assumes is safe enough for random users to use, but that may still contain bugs that weren't caught by the few beta testers. By releasing it to a greater number of people, it makes it easier to find bugs that were missed.

Release is the last stage which is published for users in general.

Build or Commit Version

A software may also have a build version or commit hash that indicates what exact version of its source code was used to created the executable program.

This occurs because in development changes to the source code are done in batches called "commits," but a single commit doesn't necessarily add a whole feature, or fixes a whole bug. The build version lets the developer know exactly at which stage of the changes to the source code you were when something happened in the application. There are tools to help track changes to the source code which will let the developer know which files were changed or weren't changed so they'll be able to tell which change exactly broke the program, or which ones didn't fix the bug.

Nightly Version

A nightly version is an automatic build of the program's source code created daily, or rather, nightly, after everyone is done coding for the day, presumably. The nightly version has the latest changes, and so it's the most unstable one. In some cases, the nightly version may not even actually run because the most recent commits rendered the program unusable.

Major open source applications like Krita offer automated nightlies where you can download a version built from the latest source code. These are intended for testing fixes, as the application developers would be able to build the application from the source code themselves. For example, if you report a bug and a developer asks if it has been fixed in the nightly, they're telling you to download the unstable, latest version and check if the program is still broken that way you said it were.