Software Version Numbers Explained

Release vs. Build Numbers

First of all, I have to say that the conventions used for determining software versions vary from company to company, and being a software developer myself, I doubt I use the same conventions as anyone else. For the most part, they are the same, but there are little discrepancies everywhere so you can never be 100 percent sure.

To understand what software version numbers mean, you first need to understand what the process is that software goes through before it is finished (and of course, software is never truly "finished"--rather, it is updated and made better). When a developer comes up with an idea for a program (or is requested by a customer to make a specific program) then the first stage of development begins, which is the conceptual stage.

Conceptual Stage:

This first stage is when a program is nothing more than a few ideas floating around. The developer might go over them a time or two, make some changes, and do basic planning as far as what is to be accomplished. The main goal of this stage is to get the program from ideas into plans. No version numbers are used at this time.

Planning Stage:

This is arguably the most important stage of the program, which involves getting a little deeper into what things the program is actually going to accomplish, disregarding how these things are going to be done. The planning in this stage is more fleshed out than the ideas from before, and much more organized. However, any actual coding or development of the program has yet to take place. Therefore, no version numbers are used in this stage, either.

Development Stage:

My personal favorite, this is when things get down and dirty and you begin to see actual parts of the program taking shape, usually in the form of application code, depending on the languages being used as well as the function of the program. This is usually the second longest stage, and is where these "version numbers" begin to mean something. In this stage of development, the program will never be available to the public because it is too unstable or unfinished to be of use to anyone. This is where "build numbers" come into play. The pre-release builds usually have numbers like 0.1, 0.2, 0.3, and so forth. Any version number that is less than 1.0 means that the program has not yet been released. Generally, a program will make it to about version 0.9 by the end of this stage, and then it is pretty much ready for its first release at version 1.0.

Testing Stage:

This kind of overlaps with the development stage, because testing is a constant process that takes place as the program is being coded. Once a certain part of the program is finished, that part is tested to be sure it works. If it doesn't work, the programmers get busy fixing its problems before moving on to a different part of the program. Minor revisions to the program are what up its build number. Let's say that I'm developing a program similar to Windows Notepad, and the function that opens files causes errors if the file is not a .txt extension. We'll assume this program is currently at version 0.4. Once this error has been fixed, the next time the program is "built" or compiled in order to be tested, the build version goes up by 0.1. The version that finally has a file open function that works will be called version 0.5, because the problem with version 0.4 has been fixed.

Release Stage:

Once all the development and testing is complete, it's finally time to make a release version. You tidy up the code one last time, put the "icing on the cake" so to speak, push the version up to 1.0, and put your program out on the market. But then, after quite a few people have bought it, you get e-mailed about a minor glitch that occurs on systems that have an older DLL version of a DLL that your program requires. Now you've got to release a new version to fix this, which you'll likely call version 1.1. This number is now a release version, because the public now has access to it. So in this stage, the program is never truly "finished" because you will always have new things to update on it.

Update Stage:

After version 1.5 or whatever it is now has been on the market for a while, and people seem to be losing interest, it's time for an updated version. Instead of just fixing a few minor things, it's time to completely re-do everything and make it ten times better than it was before. Now, when it is released, it will be called version 2.0, because it's twice as useful as the original. It will have better features, or at least a lot more of them. It will probably cost a lot more than the original version, although now you have a contingent of people willing to pay more because they know how good the original was, and can't imagine what the new version will be like. And of course, if there's a patch or something that you release sometime after the update, it will be called version 2.1.

This is pretty much the end of the continuum. The program will continue to be updated and added to, and maybe even get to version 3 or 4. However, some software companies decide to let out "pre-release versions" that normally aren't available to the public. They might be for certain members of the company or affiliate companies, or maybe just to get customers excited and sell more copies when the whole thing comes out. Usually this only happens with fairly large releases, such as an enormous 3D game or a popular email client. These stages are explained below:

Pre-Release Stage:

This is sometime during the development stage when the programmers have accomplished quite a bit and want to show it off without releasing it to the public. They might decide to release a "beta" version, which means that it is the version that the software testers (beta testers) have to test. Therefore, beta versions are not guaranteed to be stable; that is, they imply a use-at-your-own-risk policy, but users who are brave enough to trust the company can have a go at seeing the new features of the program without actually having to buy it (most pre-release versions are free, but only available to a select few individuals). The second type of releases are called "RC" versions. The RC stands for release candidate, and this type of release happens more towards the program's completion. In fact the reason they are called release candidates is that the developers are considering releasing that exact version, but they want to test it out on a smaller portion of customers to see what the reaction is or how well the product is going to sell.

I hope this helped to clear things up.

More by this Author

Comments 3 comments

softwareqatesting 7 years ago

Was searching for "release control” and saw hubpage. Great info on build control process. Good work!


Software QA Testing

ciidoctor profile image

ciidoctor 7 years ago

i donot know that they have any mean thank you very much for such info

sbyholm profile image

sbyholm 6 years ago from Finland

Interesting with a hub on versions. There's a lot of different systems out there for marking software. In the end what matters is that the system you use lets you identify exactly what software you have.

Given a version number you must be able to find the right source code and documentation revisions for debugging and customer support.

On my last job we had a simple system with three numbers 1.2.3 where if the last number was odd it was a development version for internal use and if the last number was even it was a released version.

So basically anything someone would compile and run would have an odd number and when the software was tested and ready for release the number was changed to the next even number, released, and then changed to the next odd number.

This to make sure there would never exist more than one build with the same even version number. It helps when a customer has a problem to know exactly what they are running.

There is always the possibility that some enthusiastic salesperson send out a development version to a customer to allow them to test some new feature in advance.

With the odd version number it's then easy to tell the customer to upgrade to the real version when they are reporting bugs for the test version.

This can also be solved with a build number that are automatically incremented on every build to guarantee that no two builds have the same number.

So in our system a software could have version 1.2.4 build nr 10342 where the build nr would increase by one every time someone hit the compile button.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.

    Click to Rate This Article