We never update chromeos_version.sh by hand, it is all automated by the branch utility, the only time we have had to mess with it is when something breaks in branch-util.

As such the branch utility should maintain this functionality I would think.

When would we not want to bump the version on the new branch?

The new branch version will still be automatically bumped by `cros branch`. There, the cases are well-defined: if we branched from a .0.0, we increment branch version; if we branched from a .N.0, we increment patch.

The trouble is with the source branch (master). It seems wonky to bump versions every time we have a branch, even for e.g. stabilize branches off old versions, yet the branch-util does this.

Do you have any input on the intended behavior here? Everything I know I've learned from tracing the original branch-util, but it'd be nice to have a well-defined specification for when master version should be touched.

I think I may be confused here, is this something it just does locally/internally and never publishes?

I agree that the branch-util should not be making commits to master chromeos_version.sh and publishing them, and it does not seem to do so. I just created a branch of a branch this morning and it resulted in https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+/8e5ba3065b9d7abed6b388b70e2bc50c50fa5bd2 on the branch, but master shows no sign of such a change https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+log/master 

So at least the branch-util from back in the day when it still worked did not seem to actually commit this sort of thing.

In summary, we should not be touching master chromeos_version.sh ever from the branch utility, we should always be touching the branch chromeos_version.sh from the branch utility.

In your example, it would have touched chromeos_version.sh on the branch that you branched off, not master.

On second inspection, branch-util appears to touch master only if (a) we are creating a release branch or (b) we are explicitly branching off ToT. There are clearly some "quick hack" shenanigans going on in this code. Sigh.

But anyway, I appreciate your assessment. So how does your opinion factor into release branching? Should milestone be incremented automatically?

If the branch utility is doing it now then it should continue to do so. 

I think the milestone concept is not really baked into it though, the milestone (e.g. M72) is a property of the browser so we only get a new milestone when the Chrome version kicks up a notch.

Even branching a release branch from master I don't see why it would need to touch the master version of chromeos_version.sh, I think on master the only thing that should be revving this is the release builder.

A logical operation should encompass all of the necessary pieces to perform that operation in a repeatable and automated way.  If that means updating chromeos_version.sh then it should do that, or review why that file needs updating and consider changes to the dependencies for branching.  

I don't want to see any automation where:

1. Perform this simple single operation
2. Oh and don't forget to also do this to, separately.

Why is updating chromeos_version.sh bad if:
a) it's already doing that?
b) it must do that?

There was a misunderstanding on my part. It appears branch-util was refactored some time ago to only touch master when creating release branches, and the surrounding comments and code were not updated to make this clear. There is logic for "which master version should be updated," but it only ever hits the release branch path, which increments chrome_branch.

Evidence this is still happening on master:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/0070f12b97f878c1018d761b6ac3487d24a9cd91

So I guess `cros branch` should still do it.

Even if `cros branch` does do this automatically, I could still move the logic to `cros version` and just call that script from cros branch. Depends if it's useful for build recipes.

I'm pretty sure that the ChromeOS release number (R72) doesn't update based on the Chrome release number (M72). Perhaps this logic should be moved into the chrome update tool, so branching code doesn't need to think about it at all?

If you do end up changing how chromeos_version.sh is updated I would be very happy if you moved the actual version data into a separate file e.g. `chromeos_version.conf` that is just read by chromeos_version.sh. Mutating a shell script has always felt fragile and unnecessary to me.

i don't think we need a CLI tool for it.  defining a better file format and a chromite lib for working with it should be sufficient.