There is no next build. On that branch.
Idealized version of our scheme.
Version identification on any branch is PRETTY_BRANCH_NAME-build and PRETTY_BRANCH_NAME is fixed at branch creation.
Our branching scheme(*) is the following:
Top level branches, the PRETTY_BRANCH_NAME of each is a code name, speaking of version number at that level is meaningless, there may be a planned scheme but it will change before the release.
a TNG (the next generation) branch where long term development is made. Often we don't even have it and it has never (release) subbranches.
a TCG (the current generation) branch where current development is made. PRETTY_BRANCH_NAME is a code name.
a TPG (the previous generation) branch. Often no more development is made here, but there may be activity in the subbranches.
A subbranch is made of a top level branch (of TCG, in presence of slow migration of TPG) when beta for a major release start. The PRETTY_BRANCH_NAME is something like "1.3.X" (X is the letter, not the digit, it means we intend to deliver 1.3 releases from here), feedback from beta is token into account here while work for the next major release is done on the TCG branch.
Ideally, release should be snapshot on that branch, but we know we aren't perfect and often need to do last minute changes while allowing others to continue to work for the next minor release. Thus subsubbranches are made for the final stabilization with pretty names being the official version number (at that time even marketing won't want to change it) like "1.3", "1.3.1" out of the "1.3.X" branch, the last build on each is the release.
If we had a fourth level, the subsubbranches names would have been "1.3.0.X" out of which we'd have had sub^3branches "126.96.36.199" "188.8.131.52".
(*) At the release level. There may be project subbranches on each of these.