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 > > > > > >
