We cannot do (clean) merges; both branches contain unwanted changes in the other branch. So, we have to cherry-pick regardless where we merge first. With post commits running automatically on master only, that seems like a logical starting point. But, it doesn't matter really -- either way works.
On Mon, May 8, 2017 at 12:30 PM, Robert Bradshaw < rober...@google.com.invalid> wrote: > 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 <da...@apache.org> 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 <tg...@google.com.invalid> > > 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 <dhalp...@apache.org> > 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 > <k...@google.com.invalid > >> > > >> > wrote: > >> > > >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci <da...@apache.org> > >> 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 > >> > > > >> > > >> >
