+1 to remove this, I have not encountered such a strong case.
best, JingsongLee
--
From:Kenneth Knowles
Time:2017 May 9 (Tue) 05:45
To:dev
Subject:Re: [DISCUSS] Remove
Interesting!
I believe the only thing we need to change to remove it for FSR is
https://github.com/apache/beam/blob/master/sdks/java/core
/src/main/java/org/apache/beam/sdk/state/Timer.java#L60
Here is how I might summarize the possibilities, at the risk of having
something quite wrong:
-
Thanks everyone!
On Mon, May 8, 2017 at 12:05 PM, Stas Levin wrote:
> Congrats!
>
> On Mon, May 8, 2017, 20:07 Tyler Akidau
> wrote:
>
> > Very nice. Congrats!
> >
> > On Sun, May 7, 2017 at 4:38 AM Prabeesh K. wrote:
> >
The release candidate #1 for the version 2.0.0 has been built.
The complete staging area is available for review, which includes:
* JIRA release notes [1],
* the official Apache source release to be deployed to dist.apache.org [2],
which is signed with the key with fingerprint 8F0D334F [3],
* all
Based on the process previously discussed [1], I've seeded the acceptance
criteria document [2].
Please consider contributing to this effort by:
* proposing additional acceptance criteria, and/or
* supporting criteria proposed by others, and/or
* validating a criteria.
Please note that
On Mon, May 8, 2017 at 1:12 PM, Dan Halperin
wrote:
> I like putting in master then CPing into release, because we should have a
> high bar for what goes into release. It should absolutely NOT default to
> everything; we should have to justify everything.
Agreed the
I like putting in master then CPing into release, because we should have a
high bar for what goes into release. It should absolutely NOT default to
everything; we should have to justify everything.
E.g., https://github.com/apache/beam/pull/2958 - where I open the CP but
suggest this may not be
On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci 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
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.
I think we agree that emitting from FinalizeBundle without specifying
the Window explicitly should be an error for anything but the global
window (similar to global combine with defaults). The question is
whether it should be allowable in the global window case for
convenience (again, similar to
I also have a definite (I guess that's closer to strong that slight)
preference for 2.0.
With version numbers, a gap is less likely to cause trouble than the
ambiguity of an overlap, and easy to document (vs. with ambiguity, one
wouldn't even think to consult the documentation without knowing the
I vote for 2.0.
On Sun, May 7, 2017 at 7:50 PM, Prabeesh K. wrote:
> I also vote for 2.0.
>
> On 5 May 2017 at 21:33, Hadar Hod wrote:
>
> > I also vote for 2.0, for the same reasons Dan stated.
> > As Cham mentioned, we can clarify any
I wanted to bring this up before the First Stable release and see what other
people think. The methods I’m talking about are:
void deleteTimer(StateNamespace namespace, String timerId, TimeDomain
timeDomain);
@Deprecated
void deleteTimer(StateNamespace namespace, String timerId);
@Deprecated
13 matches
Mail list logo