By using this site, you agree to our Privacy Policy and our Terms of Use. Close

I don't really know if this means anything.

Does 1.1 usually indicate a launch version and anything after is bug fixing?



Around the Network
Ryuu96 said:

I don't really know if this means anything.

Does 1.1 usually indicate a launch version and anything after is bug fixing?

It depends on each team's nomenclature for how they update build #'s but typically 1.0 is what they'd assign to a "Gold" or release version. The first number behind the decimal would usually indicate a larger bug fix patch, while subsequent numbers behind decimals would track smaller and smaller fixes. Numbers behind decimals are also usually reset to 0 when a higher increment is added to a higher decimal placement (# further along the left). 

So looking at your examples, Fallout had 1 major bug fixes update for launch while Starfield has had 6 plus an additional 35 smaller fixes. 

Increasing the left-most number usually indicates a much larger feature addition and compilation of bug fixes and is often associated to big content releases or done in association with DLCs that come with major new features/QoL updates (ex. No Man's Sky is at version 4.13 and the version numbers are associated with certain bigger updates they've released). 





trasharmdsister12 said:
Ryuu96 said:

I don't really know if this means anything.

Does 1.1 usually indicate a launch version and anything after is bug fixing?

It depends on each team's nomenclature for how they update build #'s but typically 1.0 is what they'd assign to a "Gold" or release version. The first number behind the decimal would usually indicate a larger bug fix patch, while subsequent numbers behind decimals would track smaller and smaller fixes. Numbers behind decimals are also usually reset to 0 when a higher increment is added to a higher decimal placement (# further along the left). 

So looking at your examples, Fallout had 1 major bug fixes update for launch while Starfield has had 6 plus an additional 35 smaller fixes. 

Increasing the left-most number usually indicates a much larger feature addition and compilation of bug fixes and is often associated to big content releases or done in association with DLCs that come with major new features/QoL updates (ex. No Man's Sky is at version 4.13 and the version numbers are associated with certain bigger updates they've released). 

Pretty much this. Also, my guess for the rightmost number is that it may be reserved for hotfixes on a prod (not realistic in a video game because it will cause an insane level of downloads for client users) or a prod-ready (more realistic) version. Since up to this point no released version existed this number may simply have not been used at all. Now there's a release version (reviewers version) it's possible will see this number change from time to time but should be reset every time a new major/minor is released.

While a game is in full dev with no release version QA simply identifies from the dev build and logs any bugs they see and devs will simply create new minors for the fixes. But when there is a release version, as well as reviewing dev builds QA must also review in depth any version that has been identified for release (in this case) 1.6.35.0. Any bugs logged by QA while reviewing this version will be fixed through a hotfix (a branch of development that is created with the tagged-for-release version as source) which will increase the hotfix number (rightmost).

Another use of this number may simply be a build number or unique identifier for the build agent that performed the build, but I doubt those here since 0 would not be possible.

Edit: found this simplified image to illustrate what I'm talking about :

Last edited by EpicRandy - on 18 August 2023

Ryuu96 said:

I don't really know if this means anything.

Does 1.1 usually indicate a launch version and anything after is bug fixing?

This may feed into the rumor that the game was "done" in time for it's original Holiday 2022 release window, but was delayed twice, first to Spring 2023 and then to September, to become the most polished Bethesda game on release. 1.0 would usually be the Gold/release version with 1.1 being the day one patch on most games (including Bethesda's own Skyrim and Fallout 4), the fact that they are already on 1.6.35 definitely suggests that they have been patching it for quite a long time. The 6 means the game had 6 major patches and the 35 means it had 35 smaller patches or hotfixes. Big patches that would add to the first decimal after the 1, so the 6 in this case, usually take devs a month or more between each post launch. For instance I believe Redfall is only on v1.11 right now in August after launching in May, it had its .1 big update in early June and it's .11 hotfix in late June, nothing since then afaik, they will likely release the 1.2 patch notes before too long. 

Last edited by shikamaru317 - on 18 August 2023

Around the Network
EpicRandy said:

Pretty much this. Also, my guess for the rightmost number is that it may be reserved for hotfixes on a prod (not realistic in a video game because it will cause an insane level of downloads for client users) or a prod-ready (more realistic) version. Since up to this point no released version existed this number may simply have not been used at all. Now there's a release version (reviewers version) it's possible will see this number change from time to time but should be reset every time a new major/minor is released.

While a game is in full dev with no release version QA simply identifies from the dev build and logs any bugs they see and devs will simply create new minors for the fixes. But when there is a release version, as well as reviewing dev builds QA must also review in depth any version that has been identified for release (in this case) 1.6.35.0. Any bugs logged by QA while reviewing this version will be fixed through a hotfix (a branch of development that is created with the tagged-for-release version as source) which will increase the hotfix number (rightmost).

Another use of this number may simply be a build number or unique identifier for the build agent that performed the build, but I doubt those here since 0 would not be possible.

Edit: found this simplified image to illustrate what I'm talking about :

So this is really different from one company to another (I'm working in software development since 20+ years now :)).

They all have different branching and versioning strategies obviously but overall; it looks the same. Again, there is no "template" or unique way to do it but at the end, it is quite equivalent.

What you are showing here is the branching strategy, basically how things are being produced, when are they merge to the main branch (trunk) and so on for each bug fixes, new features, etc... As you never want to have developers coding directly in the production branch, it would be really bad :D 

They are 2 ways to do that tho, either your trunk is the main production branch, or (and I think that what BGS is doing), there is a branch created for each version (1.6.35) from the trunk at a specific time. So in your diagram it would add another row on top with one dot for each of those build (and those would not move in time, maybe some hotfix would be backported from trunk but this should be very exceptional)

Now when we talk about the version number, it can be related or not. But usually. The first number is the 'major version', the second is the 'minor version', the third one, is the branch version and the last one is usually the "build number".

Looking at it quickly, in that case I would assume that 1 is the major version, 6 the minor version (and this goes up whenever they decide to, it maybe be when they add a new feature, or when a sprint is over, etc) and the 35 would probably be the official build number. The last 0 is probably for any hotfix bundle if required (a patch basically with really important hotfix backported from trunk and which cannot wait for the next "official" build/release). (you basically nailed it:))

Internally they definitely have more build obviously but this probably the official build handed over to QA (and us). 

Last edited by Imaginedvl - on 18 August 2023

So COD MWIII is still on last gen ^^'?  

Would have been a good time to upgrade..






konnichiwa said:

So COD MWIII is still on last gen ^^'?  

Would have been a good time to upgrade..

With how compatible MW3 is to MW2 with most of your unlocked items moving over to the new game, it was most likely an asset and engine flip that they used to make a new game. Like Breath of the Wild to Tears of the Kingdom. Improvements, yes, but not enough that would require current-gen hardware. 



You called down the thunder, now reap the whirlwind

Imaginedvl said:
EpicRandy said:

Pretty much this. Also, my guess for the rightmost number is that it may be reserved for hotfixes on a prod (not realistic in a video game because it will cause an insane level of downloads for client users) or a prod-ready (more realistic) version. Since up to this point no released version existed this number may simply have not been used at all. Now there's a release version (reviewers version) it's possible will see this number change from time to time but should be reset every time a new major/minor is released.

While a game is in full dev with no release version QA simply identifies from the dev build and logs any bugs they see and devs will simply create new minors for the fixes. But when there is a release version, as well as reviewing dev builds QA must also review in depth any version that has been identified for release (in this case) 1.6.35.0. Any bugs logged by QA while reviewing this version will be fixed through a hotfix (a branch of development that is created with the tagged-for-release version as source) which will increase the hotfix number (rightmost).

Another use of this number may simply be a build number or unique identifier for the build agent that performed the build, but I doubt those here since 0 would not be possible.

Edit: found this simplified image to illustrate what I'm talking about :

So this is really different from one company to another (I'm working in software development since 20+ years now :)).

They all have different branching and versioning strategies obviously but overall; it looks the same. Again, there is no "template" or unique way to do it but at the end, it is quite equivalent.

What you are showing here is the branching strategy, basically how things are being produced, when are they merge to the main branch (trunk) and so on for each bug fixes, new features, etc... As you never want to have developers coding directly in the production branch, it would be really bad :D 

They are 2 ways to do that tho, either your trunk is the main production branch, or (and I think that what BGS is doing), there is a branch created for each version (1.6.35) from the trunk at a specific time. So in your diagram it would add another row on top with one dot for each of those build (and those would not move in time, maybe some hotfix would be backported from trunk but this should be very exceptional)

Now when we talk about the version number, it can be related or not. But usually. The first number is the 'major version', the second is the 'minor version', the third one, is the branch version and the last one is usually the "build number". 

Looking at it quickly, in that case I would assume that 1 is the major version, 6 the minor version (and this goes up whenever they decide to, it maybe be when they add a new feature, or when a sprint is over, etc) and the 35 would probably be the official build number. 

Internally they definitely have more build obviously but this probably the official build handed over to QA (and us). 

Yes, I also have been working in software development for 12 years in my case. I've seen many branching strategies being tried in various projects some work better than others depending on the context.

e.g. A web app may be treated differently than desktop software because you have more leeway to do as much release as you want. in video game releases cause users to download the new version so 'Hotfixes' on the released version would likely be avoided and the branching strategy will likely be adjusted so that the main branch acts as QA-ready and not an actual released version representation. You will still likely release from the main branch but specific tag instead of the latest revision.



gtotheunit91 said:
konnichiwa said:

So COD MWIII is still on last gen ^^'?  

Would have been a good time to upgrade..

With how compatible MW3 is to MW2 with most of your unlocked items moving over to the new game, it was most likely an asset and engine flip that they used to make a new game. Like Breath of the Wild to Tears of the Kingdom. Improvements, yes, but not enough that would require current-gen hardware. 

Just think it could have been a great bundle with xbox series s 1TB edition and an extra incentive ' to upgrade'.