Ok since there were not many issues I did the 'update' for the misplaced issues to version 2.10. We are good to go. New resolved issues in master musg go now into 2.11.0
On Wed, Jan 16, 2019 at 10:38 AM Ismaël Mejía <ieme...@gmail.com> wrote: > > This means that the tickets resolved and marked for 2.11 since January > 2 should be reviewed and retargetted to version 2.10. > So this is a call for action for committers who have merged fixes > after the cut to update the tickets if required. > > Ismaël > > On Tue, Jan 15, 2019 at 9:22 PM Kenneth Knowles <k...@apache.org> wrote: > > > > As a heads up, I did not realize that the release guide specified a custom > > process for starting a release branch. It makes sense; > > cut_release_branch.sh consolidates knowledge about all the places the > > version is hardcoded in the codebase. To keep the history simple, I will > > re-cut the release branch at the point where master moved from > > 2.10.0-SNAPSHOT to 2.11.0-SNAPSHOT. All PRs to the branch have been > > cherry-picked from master, so they will all be incorporated without any > > action by their authors. > > > > Kenn > > > > On Tue, Jan 15, 2019 at 10:31 AM Kenneth Knowles <k...@google.com> wrote: > >> > >> I'm on it. > >> > >> On Tue, Jan 15, 2019 at 8:10 AM Ismaël Mejía <ieme...@gmail.com> wrote: > >>> > >>> There is also another issue, after the 2.10.0 branch cut some > >>> identifier in the build was not changed and the Apache Beam Snapshots > >>> keep generating SNAPSHOTS for 2.10.0 instead of the now current > >>> 2.11.0-SNAPSHOT. Can somebody PTAL? > >>> > >>> On Thu, Jan 3, 2019 at 6:17 PM Maximilian Michels <m...@apache.org> wrote: > >>> > > >>> > Thanks for driving this Kenn! I'm in favor of a strict cut off, but I'd > >>> > like to > >>> > propose a week for cherry-picking relevant changes to the release > >>> > branch. It > >>> > looks like many people are returning from holidays or are still off. > >>> > > >>> > Cheers, > >>> > Max > >>> > > >>> > On 02.01.19 17:20, Kenneth Knowles wrote: > >>> > > Done. I've created the Jira tag for 2.11.0. > >>> > > > >>> > > Previously, there was a few days warning to get things in before the > >>> > > branch is > >>> > > cut. You can just cherry-pick them. This is a bit better for release > >>> > > stability > >>> > > by avoiding all the other changes on master. The timing of the cut is > >>> > > always > >>> > > going to include older and newer changes anyhow. > >>> > > > >>> > > Kenn > >>> > > > >>> > > On Wed, Jan 2, 2019 at 1:08 PM Ismaël Mejía <ieme...@gmail.com > >>> > > <mailto:ieme...@gmail.com>> wrote: > >>> > > > >>> > > Can you please create 2.11 tag in JIRA so we can move the JIRAs > >>> > > that > >>> > > are not blocking. I have quite a bunch of pending code reviews > >>> > > that > >>> > > hoped to get into this one but well now probably they shall wait. > >>> > > (My > >>> > > excuses for the people who may be impacted, I had not checked > >>> > > that the > >>> > > date was in the first week). > >>> > > > >>> > > On Wed, Jan 2, 2019 at 4:45 PM Jean-Baptiste Onofré > >>> > > <j...@nanthrax.net > >>> > > <mailto:j...@nanthrax.net>> wrote: > >>> > > > > >>> > > > It sounds good to me. > >>> > > > > >>> > > > Regards > >>> > > > JB > >>> > > > > >>> > > > On 02/01/2019 16:16, Kenneth Knowles wrote: > >>> > > > > Hi All, > >>> > > > > > >>> > > > > According to the release calendar [1] branch cut date for > >>> > > > > Beam 2.10.0 release is today, 2019 January 2. I'd like to > >>> > > volunteer to > >>> > > > > manage this release. Does anyone have any reason we should > >>> > > not release > >>> > > > > on schedule? > >>> > > > > > >>> > > > > Otherwise, if you know of release-blocking bugs, please mark > >>> > > their "Fix > >>> > > > > Version" as 2.10.0 and they will show up in the burndown > >>> > > [2]. If you own > >>> > > > > a bug currently in the burndown, please double-check if it > >>> > > is truly > >>> > > > > release-blocking. > >>> > > > > > >>> > > > > I've gone ahead and cut a release-2.10.0 branch from the > >>> > > current master, > >>> > > > > since it is green. If it turns out to be an inauspicious > >>> > > starting point, > >>> > > > > we can always reset it. > >>> > > > > > >>> > > > > Kenn > >>> > > > > > >>> > > > > [1] > >>> > > > >>> > > https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com&ctz=America%2FLos_Angeles > >>> > > > > [2] > >>> > > https://issues.apache.org/jira/projects/BEAM/versions/12344540 > >>> > > > > >>> > > > -- > >>> > > > Jean-Baptiste Onofré > >>> > > > jbono...@apache.org <mailto:jbono...@apache.org> > >>> > > > http://blog.nanthrax.net > >>> > > > Talend - http://www.talend.com > >>> > >
