An alternative strategy, given the number of outstanding changes, would be to create release-intended PRs against the release branch itself, then periodically merge back to master. This would reduce the need for manual (and error-prone) cherry-picking.
On Fri, May 5, 2017 at 5:21 PM, Davor Bonaci <[email protected]> wrote: > The release branch is now created [1]. Anything for the first stable > release should go into master as usual, and then get cherry-picked into the > release branch. > > I'll create the first RC shortly and then start a doc around the acceptance > criteria. > > From this point onward, backward-incompatible changes should *not* be > merged to master, unless they are also getting cherry-picked into the > release branch. > > Davor > > [1] https://github.com/apache/beam/tree/release-2.0.0 > > On Fri, May 5, 2017 at 1:57 PM, Thomas Groh <[email protected]> > wrote: > >> I'm also +1 on the branch. It'll help us make sure that what we're getting >> in is what we need for the FSR. >> >> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin <[email protected]> wrote: >> >> > I am +1 on cutting the branch, and the sentiment that we expect the first >> > pancake >> > <https://www.quora.com/Why-do-you-have-to-throw-out-the-first-pancake> >> > will >> > be not ready to serve customers. >> > >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles <[email protected] >> > >> > wrote: >> > >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci <[email protected]> >> wrote: >> > > >> > > > I'd like to propose the following (tweaked) process for this special >> > > > release: >> > > > >> > > > * Create a release branch, and start building release candidates >> *now* >> > > > This would accelerate branch creation compared to the normal process, >> > but >> > > > would separate the first stable release from other development on the >> > > > master branch. This yields to stability and avoids unnecessary churn. >> > > > >> > > >> > > +1 to cutting a release branch now. >> > > >> > > This sounds compatible with the release process [1] to me, actually. >> This >> > > thread seems like the dev@ thread where we "decide to release" and I >> > agree >> > > that we should decide to release. Certainly `master` is not ready nor >> is >> > > the web site - there are ~29 issues as I write this though many are not >> > > really significant code changes. But we should never wait until >> `master` >> > is >> > > "ready". >> > > >> > > We know what we want to get done, and there are no radical changes, so >> I >> > > think that makes this the right time to branch. We can easily cherry >> pick >> > > fixes for our burndown list to ensure we don't introduce additional >> > > blockers. >> > > >> > > Some of the burndown list are of the form "investigate if this >> suspected >> > > bug still repros" and a release candidate is the perfect thing to use >> for >> > > that. >> > > >> > > [1] https://beam.apache.org/contribute/release-guide/# >> decide-to-release >> > > >> > >>
