The logic behind software version numbering?

[Some1]

I've always wondered how these software version numbers are given. - Have you?
I hope with some help we can figure it out, and hopefully someone with knowledge can help us in the process!

There's even an article about Software Versioning on Wikipedia: http://en.wikipedia.org/wiki/Software_versioning
Based on article the Civ5 seems to go under:

Designating development stage

Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.

It can be used in the third position:

* 0 for alpha (status)
* 1 for beta (status)
* 2 for release candidate
* 3 for (public) release

For instance:

* 1.2.0.1 instead of 1.2-a
* 1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
* 1.2.2.3 instead of 1.2-rc (release candidate)
* 1.2.3.0 instead of 1.2-r (commercial distribution)
* 1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)

So far, with the Civ5 we have had:

• The initial version, which I assume was 1.0.0.00 or just 1.0.0.0
• 1.0.0.17
• 1.0.0.20
• 1.0.0.62

Where do these numbers come from in case of Civ5? Are the 17, 20 and 62 the numbers of issues fixed or something?

 

[r_rolo1]

No, those numbers are simply the number of patches made by Firaxis so far, not all of them public OFC .62 means simply that firaxis already developed 62 patches so far.

 

[Some1]

No, those numbers are simply the number of patches made by Firaxis so far, not all of them public OFC .62 means simply that firaxis already developed 62 patches so far.

And 3 out of 62 is released to date? Hmmm, need more info to believe that!

 

[Aybara]

I think what he meant is that there have been 62 "patches" that have been made all compiled into patch 1, 2, and 3

 

[zurichuk]

I'd call them 'builds' rather than patches, 62 builds of which 3 have been in a situation to create a patch.

 

[mtrein]

In software development, the last number in a version usually means the number of builds. The number '62', for example, would be the 62nd time all file changes to the game coding have been recompiled together. Each time this is done they add one to the number.

 

[r_rolo1]

Exactly. Firaxis has been quite consistent in their version numbering since civ III : the number of the patch is the number of "patches" made so far for that game or x-pak. Obviously not all of those "patches" are public and most of them are just fixes for specific problems instead of wide spectrum solutions...

 

[mujambee]

Those numbers mean probably that the missing ones where rejected by their quality assurance team.

i.e. : patches 1.0.0.21 to 1.0.0.61 had blocking issues that rendered them unsuitable for public release.

 

[lockstep]

So far, with the Civ5 we have had:

• The initial version, which I assume was 1.0.0.00 or just 1.0.0.0
• 1.0.0.17
• 1.0.0.20
• 1.0.0.62

IIRC, the "initial" version had the number 1.0.0.07 (or 1.0.0.7) and probably included a day-zero-patch.

 

[Ktulu]

Those numbers mean probably that the missing ones where rejected by their quality assurance team.

i.e. : patches 1.0.0.21 to 1.0.0.61 had blocking issues that rendered them unsuitable for public release.

No. It's not like they were trying to make 1.0.22 and everything up to .61 the release patch. The final patch features were likely only in the last 5 or 6 builds. They don't implement everything at once and send it off for testing, it's a gradual process.

As has been already said the last number is simply the number of builds.

 

[Justicex]

It's simply a code to verify that everyone is working on the same build. It's a numerical list of patches, design changes, whatever have you. I saw the same thing at work. I would get designs for parts for me to create in my machine and the diagrams would have codes like that too.

 

[Murky]

Versions are just a way to track changes. It's up the the designers/programmers/builders to decide what the increments are. Most companies have their own version standards or they use industry standards.

Often times software releases are broken down in segments. There are also different categories for releases that have different effects on the version numbers. Most shops have 1.0.00 systems. Minor bug fixes usually effect the last set of digits. The 2nd digit is typically for larger milestones like adding a new feature or content (typically scheduled releases effect this). Major releases that alter the software in a big way increment the 1st digit. These types of changes require a lot of planning, development and testing so they tend to occur least often.

 

[Jharii]

In software development, the last number in a version usually means the number of builds. The number '62', for example, would be the 62nd time all file changes to the game coding have been recompiled together. Each time this is done they add one to the number.

Correct. The "build number" is typically the last number of the sequence. The public only sees the builds that are released, which is why there may be large gaps in what we see.

 

[davehcyj]

When build numbers have the form a.b.c.d and you see d frequently skipping numbers it usually means d is the build number like everyone else has mentioned already. If c changes it means there were minor feature updates (which were not planned at part of bug fixes from the d changes). If b changes it usually means major feature updates and additions. If a changes it usually means a complete overhaul and redo.

 

[Hormagaunt]

Just brought up EQ2 for a quick look, it's marked SOEBuild 7032L. Those numbers can get very large.

 

[Biz_]

in general the least significant changes add to the rightmost numbers

i.e. going from 1.0.0

to 2.0.0 means adding a lot of new things

to 1.1.0 means adding a few small features or fixing a lot of serious bugs

to 1.0.1 means fixing a bug or something

 

[Some1]

Those numbers mean probably that the missing ones where rejected by their quality assurance team.

Are you sure they have one?

 

[Some1]

Versions are just a way to track changes. It's up the the designers/programmers/builders to decide what the increments are. Most companies have their own version standards or they use industry standards.

Often times software releases are broken down in segments. There are also different categories for releases that have different effects on the version numbers. Most shops have 1.0.00 systems. Minor bug fixes usually effect the last set of digits. The 2nd digit is typically for larger milestones like adding a new feature or content (typically scheduled releases effect this). Major releases that alter the software in a big way increment the 1st digit. These types of changes require a lot of planning, development and testing so they tend to occur least often.

Can it go v.1.0.0.142 i.e. the rightmost digits go over hundred?
Or does it go then v.1.0.1.42?

When build numbers have the form a.b.c.d and you see d frequently skipping numbers it usually means d is the build number like everyone else has mentioned already.
If c changes it means there were minor feature updates (which were not planned at part of bug fixes from the d changes).
If b changes it usually means major feature updates and additions.
If a changes it usually means a complete overhaul and redo.

Could we expect to have Civ5

• v.1.1.0.0
  or
• v.1.0.1.0

when the Genghis Khan comes out?

Just brought up EQ2 for a quick look, it's marked SOEBuild 7032L. Those numbers can get very large.

Is it possible we have something like Civ5 v. 2.1.c.d then?

 

[PieceOfMind]

Off topic...

Are you sure they have one?

You know, I actually wonder that. It seems the latest patch was being worked on up to the last minute and probably didn't go through QA. The food basket always full bug and governors causing cities to starve are the sorts of introduced bugs that an observant player would pick up within 10 minutes.

Do they actually have a QA team? (sorry, I'm just mirroring your question, but not sure if yours was rhetorical - mine isn't). There's one in the manual credits, but are they still on the same project?

 

[VGT]

Can it go v.1.0.0.142 i.e. the rightmost digits go over hundred?
Or does it go then v.1.0.1.42?

If they for example use version control system and it's revisions as numbers (i use it that way), then yes - it can go over hundreds and thousands and more... v.1.0.0.1024
but in this scenario even smallest change in code (even adding comment to code) is +1 revision, so it might be different system.
Number of "builds" mentioned earlier are more likely.

Is it possible we have something like Civ5 v. 2.1.c.d then?

Again it's how i use it, so not sure if it's the same, but for me v.2.0 would be completely rewritten software, so in this case civ5 v.2.0 would be simply civ6 v.1.0
When i develop software, i stick to 1.x version as long is it's compatible backwards and not rewritten completely