0

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.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
leeyuiwah
  • 6,562
  • 8
  • 41
  • 71

1 Answers1

1

No, Gerrit can't generate a release number that can reflect the total order of changes in any branch.

You're with a wrong approach here... do not try to "migrate" the process/procedures you used in Subversion to Git/Gerrit. Git is a different tool and you need to use it differently too.

You need to use tags to mark releases.

See Git - Tagging for more details.

  • Thanks for your point. But do you think this type of conversation is reasonable? "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." – leeyuiwah Mar 23 '18 at 14:57
  • 1
    Is totally reasonable if you use tags, like: Your software installation is at release v1.2.3, but we fixed the bug only later in release v1.4.7. Where v1.2.3 and v1.4.7 are tags created with "git tag" command. – Marcelo Ávila de Oliveira Mar 23 '18 at 15:00
  • Okay. I guess we just cannot have an automatic release number. That is fine. Because for end customers, they use released products that have gone through our QA (quality assurance) cycle, so a manual tag is a small overhead. For internal users (using/testing development build), then I guess they will have to use timestamp plus some info (say, Jenkins BUILD_ID) to reason the "happens before" relationship. – leeyuiwah Mar 23 '18 at 15:25
  • 1
    If you have automated builds using Jenkins you can execute a "git describe" command to save a human readable name based on an available previous tag. See more info here: https://git-scm.com/docs/git-describe – Marcelo Ávila de Oliveira Mar 23 '18 at 18:49
  • Thanks for introducing `git describe` to me. But it seems to me the result would not be reliable enough when it comes to determining a "happens-before" relationship (or the total order). Perhaps a simple timestamp of the form YYYYMMddHHmmss (which Jenkins does offer), while a bit verbose, is a better substitute. – leeyuiwah Mar 23 '18 at 19:42