On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci <[email protected]> wrote: > 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.
Shouldn't the set of changes wanted in release but not in master be quite small (if any)? In that case, one could do an explicit revert following merge from release to master, when needed. The extra work scales in terms of how much we want to diverge (rather than all the changes we want in release that should also be in master, which is the bulk of them, touched by significantly more people.) > 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 < > [email protected]> 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 <[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 >> >> > > >> >> > >> >> >>
