This is a follow-up question to this discussion (link), which states the following assertion:
A Gerrit Change Number is typically generated monotonically increasing as new changes are submitted for review to a Gerrit server. Note, however, that since different changes may take different time to finish code review, there is no guarantee that the changes will be applied to the master branch in order (or be applied at all). As such it is possible to have a change with a larger numeric change number Y to take effect on the master branch before another change with a smaller numeric change number X. In other words, on the master branch, when there are two changes with numbers X and Y respectively, and X<Y, there is NO guarantee that X happens before Y.
Our team was migrated from SVN where we used to have a monotonically increasing number (release number) that can reflect the total order of different versions of the code. Specifically, we can tell customers that "Your software installation is at release X, but we fixed the bug only later in release Y (Y > X). So please update to a version of Y or later to get the bug fix."
Based on the assertion stated above, we cannot use Gerrit Change Number for that purpose. So here is my question:
Can Gerrit
generate a release number that can reflect the total order of changes in the master branch?
Further discussion
I understand that git
, by itself, does not guarantee a total order in the set of commits. There is only a partial order -- each commit has one or more parents and thus ancestors, but two commits J and K can be neither a descendant nor an ancestor of each other (i.e. there is no happens-before relationship between the two).
However, things are different with Gerrit
. Gerrit
is a system built on top of git
to facilitate a centralized work flow. There is a singleton master branch, and there is a total order for changes that are integrated (i.e. merged or rebased) on the master branch. If there are two distinct changes A and B integrated on the master branch, then either A happens before B, or B happens before A. As such it is not difficult to implement a feature that generates a serial number based on the integration order that happens on the master branch. And this number will have great practical use.