How is decided, if a software version is called 1.1 / 1.0.1 / / etc.?



How is decided, if a software version is called 1.1 / 1.0.1 / / etc.?

In: 1

It’s fairly arbitrary, but it may be that a given decimal place is referring to a specific feature. So the overall application is version 1, but the network interface is version 5, while the graphics are version 2 so the overall version is 1.5.2 and so on. At other times, it’s just used to denote minor differences.

It is based on Company policy. The first number is a major revision. These typically change when there is a large software functionality change. And the following numbers are minor revisions. It is up to the company how minor revisions are handled. Some Group them all together, and in that case you would only have one minor revision. Some companies break down their minor revisions in the different categories. And that is why you get the multiple decimal points.

Well windows installer will by default only override files when its newer based on the version number. It will only look at the first 3 numbers. So often windows or multiplatform software will use only the first 3 numbers. Also very often companies use the 3rd number as a kind of patch number. Meaning x.x.2 is newer as x.x.1 but does not introduce new features or breaking changes. But this is entirely decided by the company

Anyone can come up with their own system at any time, as others have mentioned

The standard is:
First number: major revision. This would be increased if the whole software was rewritten almost from scratch, or the way it works for users was completely redone, that sort of thing

Second number: minor revision. This would be for a feature update, adding something new or changing the way a subset of the software works

Third number: patch. This would be for a bug fix or some other kind of tweak

Fourth number (if exists): build. Usually not involved in public releases, it’s basically the amount of compilations done while working on the current version. But if the public sees a fourth number, like if the last patch didn’t work right and they had to rush out a fix, they might use the build number or replace it with just a .1 or .2

But again, almost every company does something different from this because it’s just an ideal

Whatever you choose really. Normally 1 is major versions with lots of new features. 1.1 is usually minor features (especially ones they couldn’t get out for the whole version release in time) and/or major fixes. 1.1.1 is usually minor fixes, no new features. Sometimes we may go to for very quick updates, like security patches.

But there is no rule. For years I’ve seen people complaining that a move from say 3 to 4 for some software doesn’t have enough changes to be worth a whole version release. I’ve seen others where people were amazed a dot release (say 3.0-3.1) contained so many improvements.

It is usually up the people who write or market the software.

There are some general assumptions that most people have but the developers and their marketing team are free to ignore the if they think it is cool or would make them more money or avoid confusion.

Usually 1.0 is the first finished complete version. Everything less than 1.0 is not yet complete and considered to be in “beta” or similar.

Smaller changes mean smaller change in numbers.

A small fix might mean it goes from 1.1 to 1.1.1 a bigger change would mean going from 1.1 to 1.2 a complete new version of the product would mean going from 1.something to 2.

Often the version number has implications for licensing. So if you pay for version 1 you have access to anything that starts with a 1.something but not perhaps for anything that starts with 2.

There may be reason to avoid things like having a version that is 2.1.1 and later on that is 2.11, especially if you have non technical audience.

At other point when you have multiple competing product with similar versioning schemes you might want to ensure that your version is the biggest one so it doesn’t seem older than the competition even if that is not reflected in the actual changes to the product itself.

You may even jump some version numbers for good or bad reasons.

In some products there might be internal version numbers hidden deep in the code that reflect what is actually happening to the code under the hood and marketing version numbers that the consumer sees and are based on what sells best.

Microsoft went Windows 7, 8 and 8.1 to 10 in part to avoid having a version 9 of windows and supposedly to avoid confusion with their Windows 95, 98 and 98 SE products from the 90s. (The official version for Windows Vista, 7, 8 and 8.1 were NT 6.0, 6.1, 6.2 and 6.3 and internally they had version numbers that were for digits long and unrelated.)

Some open source developers refuse to reach 1.0 and approach almost asymptotically without ever quite reaching it until it is perfect.

Some projects have different strands in their release cycle where even and odd numbers may carry specific meaning. Some projects keep developing different version at the same time and have a scheme that they use to make clear which releases of which versions go together.

It would be nice if there were some hard rules, but there aren’t really. The best we have is:

Bigger number means newer.

Fairly specific to the project, a lot of projects try to standardize on [semantic versioning]( which I think most use now.

Often you’ll see the repository version number (something like r125852, indicating the 125852th change), or for git it’s a hex number, often something like “35cfb2b”, that’s just a number that git uses to identify the version and it’s automatically generated.

I’ve also seen many where they follow semantic versioning, but they only release even patch versions, where odd patch versions are developer versions

The basic idea is that bigger changes get bigger numbers, and smaller changes get smaller numbers. Going from version 2.1 to version 3.0 means a huge change with entirely new features; going from version to means you fixed a misspelled word.

In reality, you can number changes however you want. There are no rules.

There’s almost no rules, only common sense. Like, first number is major version, second is minor. Version 1.0 is release version, 0.xx – is alphas and betas and prone to a lot of changes. Major version usually changes on some major code changes. Minor version changes on minor changes, correspondingly. Third and fourth number could be “revision #” and “build #”, they could be incremented automatically, or by hand, or don’t even mean revision nor build, just some even more minute version numbers. Fifth numbers is exceptionally rare, can’t say I’ve seen any version with such. Some devs increase versions like from 0.0.9 to 0.1.0, some to 0.0.10.

Overall, it’s chaos here)

It really depends on the individual product and the company that makes it.

Usually, updating a version number is a technical decision of the development team.

Many development teams (especially in the open source community) use what’s called [semantic versioning](, where the version number is A.B.C. A rolls over only for major changes that probably break related programs, B rolls over whenever new stuff is added but existing related programs should still work, and C rolls over for bug fixes and tiny improvements.

Sometimes, the version number can get less technical and more political. This especially applies to rolling over to version 1.0 (indicating a product is out of testing and ready to just be used), or going to version 2.0 (indicating the first major change ever since the product existed in a usable form as version 1.0). Deciding to say “We’re releasing OurProduct 2.0” is a big move that, especially in companies that are heavily dependent on a single product, involves the marketing department, or even the CEO.

Semantic versioning is the closest thing we have to a standard for version numbers. It’s undeniably true that a lot of products use it.

However, it’s also undeniably true that a lot of products don’t use semantic versioning.

You can probably find software versions that use two / three / four numbers, or add zeros to make it clear that 1.10 is nine versions later than 1.01, or include a letter like 1.8b, or involve the date of release instead, or don’t use numbers at all.

Microsoft Windows has infamously switched between many different version naming systems over the years. (Remember, this often happens because the marketing department takes over decision making for version numbering when a company is highly dependent on a single product, which definitely describes Microsoft historically but maybe not currently.) The versions of Windows are:

– 1.0
– 2.0, 2.1
– 3.0, 3.1, 3.11 (suddenly they add a third digit but no decimal point), NT “New Technology” (okay, now we use two-letter codenames)
– 95, 98 (now we’re switching to a year), 98SE “Second Edition” (a year with an extra two-letter “edition” abbreviation), ME “Millenium Edition” (now a 2-letter edition abbreviation with no year)
– 2000 (okay we have to use a 4-digit year now because we’re in a new century, but it’s not the same as Millenium Edition), XP “eXPerience” (now back to abbreviations but they’re just two random letters from a word and not a proper acronym)
– Vista (ditch the two-letter thing and just use the spelled-out codename instead)
– 7 (switch back to numbers, but just use a single version number)
– 8
– 10 (skip 9 because some programs think they’re running in Windows 95 / 98 if the version starts with 9)
– 11

As to why things are grouped into bullet points like that: The marketing department picked “7” because “Windows 7” sounded nice, and they later tried to [awkwardly justify after the fact]( that there were 6 prior versions. My grouping of earlier versions into bullet points is based on Microsoft’s stated justification for there having been 6 versions of Windows prior to Windows 7.