When are release build... built?

[Sans]

I doubt it is 10 min before the planned update release. But is it shipped a week before the update?

In other words: How much time between the compilation of the game and shipping it to the public ?

I hope devs could give an answer but anyone sharing its thoughts is appreciated

[Guest]

Normally the interval is really short! You make release candidate builds and submit those for final QA, and when QA declares it's ready to go, you ship it. Sometimes you ship the actual RC build, but often you rebuild it with a new version number but no other changes, and then send it out. Sometimes even a trivial thing like this can break the build, like what happened with Larian and the Baldur's Gate 3 hotfix 4!

https://baldursgate3.game/news/hotfix-4-redeployed_86

Edit: Basically, there's no reason to delay releasing a build once it's passed final QA. If you don't intend to test it anymore, why would you?

 

Edited November 30, 2023 by Periple

[NexusHelium]

I imagine a  release build is just a build they're comfortable with releasing and has been more or less optimized (But you know...). They do a final test and get rid of their normal debug tools then ship it by the required release date. But I'm not a game developer so I wouldn't know for sure (Not to mention that is probably much simplified from the actual process).

Edited November 30, 2023 by NexusHelium

[Guest]

18 minutes ago, NexusHelium said:

I imagine a  release build is just a build they're comfortable with releasing and has been more or less optimized (But you know...). They do a final test and get rid of their normal debug tools then ship it by the required release date. But I'm not a game developer so I wouldn't know for sure (Not to mention that is probably much simplified from the actual process).

It's more complicated than that. Usually a release process goes something like this:

1. A release candidate (RC) branch is created from the development branch (development will go on normally in the development branch)
2. An RC build is made from the RC branch, with unit tests + smoke tests automatically run with the build (this build won't include any development tools)
3. QA tests it according to their test plan for the release -- it's usually impossible to cover everything, so they concentrate on areas with changes, plus spot testing other things
4. QA reports any issues they find; low-priority bugs just go into the backlog, bugs they declare as blocking release get sent to the dev team
5. Devs fix the blockers in the RC branch, merge them back to the development branch <-- this can be a PITA if the development branch and RC branch have already diverged!
6. Go back to step 2, repeat until QA reports no more blockers
7. Push the final RC into production -- usually with a version number bump and rebuild like in step 2, but sometimes as-is

As you can see, this process is inherently unpredictable -- everybody would like RC1 to be the actual release, but it usually isn't, and it's really hard to predict just how many RCs will be needed and exactly what the interval between them will be. So it sometimes happens that a release is pushed at the last minute because QA finds a blocker in an RC that everybody really thought was good to go.

Edited November 30, 2023 by Periple