By using this site, you agree to our Privacy Policy and our Terms of Use. Close
EpicRandy on 18 August 2023
Edit Thread
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.