Our build number is the number of an RPM containing a fix, which has been converted from a dev build into QA. Ordinarily this will be build 3/4/5 etc. depending on the number of packages which have been put together before this (as a fictions example, for 3.2 release of OnApp, the build which moves from dev into QA may be labelled 3.2.0-6, meaning 6 previous builds)
During the QA process we expect the team to identify various issues which may require new code, once this has been sent back to dev and addressed, a new package is put together for updated QA testing. As these new packages are completed and resubmitted into the QA process they will be given a new designation by the team to reflect this new build (e.g., 3.2.0-8, 3.2.0-10 etc etc) as each new build is put back through the process.
Taking this out further beyond the QA cycle, the same principles are applied for release post GA. So, for example 3.2.2-24 release package of OnApp is ultimately a reflection of some updates which have been applied to the 3.2.2 build of the platform, and just references the latest build number containing additional updates.