Change release branching strategy to create release-1.x branch late

[saschagrunert]

Summary

Right now we're creating the release branch at the same date as we cut the v1.x.0-beta.0 release. After that release we will fast-forward (merge the latest changes from the master branch) periodically into the release branch manually.

The main idea is now to cut the release branch much later, whereas ideally we could get away from the branch fast-forward process.

Discussion

Reasons for creating the release branch early:

• It gives extra CI signal (redundant test of same commits on different branches)
• We have extra eyes on code coming from master to release branch (ie: look at all merged commits and affirm they should technically go to the release branch)
• We practice operationally the tooling and processes around shifting content from master to release branch

Open Questions

• What would be the right time to cut the release branch? (Code thaw might be too late, whereas code freeze might be sufficient)
• What needs to be done from a release engineering perspective?
• What are the dependencies (some projects might rely on early-cut Kubernetes release branches)?

[justaugustus]

@kubernetes/release-engineering -- I've left a review on the proposed 1.19 release schedule about this.
PTAL and add feedback there.

[justaugustus]

/priority important-soon
/assign @justaugustus @tpepper @cpanato @saschagrunert @hasheddan