Issue #34505 was about checking that the security branch (in the private Go repository where the security fix is developed) is merged into the public release branch.

It was meant to add a safety measure to detect a situation where the step of merging the security branch was either forgotten or incomplete by the time the next minor release is made, which would cause the minor release to not include the fix from the previous security release. (Minor releases are sometimes made in very short succession after the preceding security release, and other times after a long amount of time.)

A fix for this was implemented in CL 206437. It checks that non-security releases contain the HEAD commit from the security release branch if such a branch exists.

While discussing this safety measure with @FiloSottile and @katiehockman, Filippo came up with a strategy of checking that minor releases contain the tag of the previous minor release. We expect that to be true for all minor releases. It has some advantages:

• it will detect a problem even if the security release branches have been deleted (without being merged)
• it does not need to access the private Go repository for non-security releases, which reduces the risk of accidentally revealing an upcoming security fix

This is the tracking issue for implementing that strategy.

To be able to implement this, we will need to parse the Go version being released, and compute the tag for the previous minor release (e.g., if releasing "go1.13.8", compute "go1.13.7"). The version package may be helpful for this purpose. It may need to be extended to support beta and RC version strings, if those are in scope for this task.

/cc @FiloSottile @katiehockman @cagedmantis @toothrot