By using this site, you agree to our Privacy Policy and our Terms of Use. Close
trasharmdsister12 on 18 August 2023
Edit Thread
EpicRandy said:
Imaginedvl said:

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.

Hehehe yeah this discussion is exactly why I started with the disclaimer that it varies between teams (and sometimes even projects) and also didn't get into branching/merging strategies. Keeping it high level for the general audience here. Good to see fellow software folks though :) (been in some form of professional software development for about 18 years now).