A version number is marketing. A studio decides to call a release “2.1” or “The War Within” and keeps using that name until the next one feels big enough to warrant a new one. A build number is bookkeeping. It’s assigned by whatever system packages and ships the game’s files, it increments on essentially every push regardless of size, and a single named version can pass through hundreds of builds between a first test and a public release. When our builds tracker reports a new number, it is almost always reporting a build, not a version, and the two move at very different speeds.
Launchers expose this bookkeeping because they need it to decide what to download. Blizzard’s Battle.net client asks a public Blizzard service which build each product is on, compares the answer with what’s installed, and downloads only the difference. The same idea drives Steam: a client checks a game’s current build ID against its local one and pulls updates when they differ. For Valve’s own games, the community project SteamTracking mirrors this from the outside, keeping a public, timestamped record of when each build shipped and roughly how much changed, without needing access to Valve’s own systems.
A build number changing is not the same thing as a patch releasing. Studios test builds continually on internal and public test realms, often called a PTR, a beta, or in Steam’s terms a branch, before anything reaches the branch most players are on by default. Steamworks documentation describes branches as specific builds a developer can make available privately or publicly alongside the main release; a player has to opt in through their client’s properties to see one. A build climbing on a PTR branch is a studio iterating in view of anyone watching, not a signal that the live game is about to change, and a tracker that reported every PTR build as “a new patch” would be wrong far more often than it was right.
None of this touches the games’ actual content. A build number and a file count are operational facts a studio’s own distribution system chooses to expose publicly; they say nothing about what changed inside the files, and we don’t try to find out by digging through them. HoYoverse and Nintendo get less still. Both publishers’ games are common subjects of community datamining that goes well past build numbers, into unreleased characters and story content pulled from update files before either company has said anything publicly, and we don’t read game files for either of them at all. For a HoYoverse game the only thing we show is the version number its App Store listing states, which the listing makes public by design; for Nintendo we track no game.
Blizzard’s public listing covers more than the games you can play. Alongside the live game and its public test realms sit vendor, QA, dev, release-candidate, event, staff and demo branches: internal builds made for people inside or around the studio, whose files are usually encrypted. We go no further than what the public listing shows: we never open, decrypt or download a branch, and we show none of its internal names. A new build on an internal branch is not a release and nothing you can play. It’s a sign the team is actively working on that game, or, when we can’t tell which game a branch belongs to, on some project we can’t yet name. We show these separately from public builds for exactly that reason: an internal branch getting a build is a team’s ordinary Tuesday, not news about the product players will eventually see.