Hey,
I think we came to the agreement that this PR is not mergeable right now,
so I am closing it. I personally find it inconsistent to not have the fully
API mirrored in Scala though, but this is something that we can revisit
when prepairing 2.0.
Best,
Marton
On Mon, Mar 14, 2016 at 8:14 PM, S
+1 for considering this as a bug.
However, I do realize that API compatibility is extremely important when
you commit to it, even if present behavior is not ideal.
Silly idea (which is only applicable to Scala APIs, unfortunately): I'm
currently working on a set of API extensions to solve FLINK-1
I agree with Aljoscha on this one, because `DataStreamSink` only contains
setters which are compatible with the Scala API.
On Mon, Mar 14, 2016 at 11:02 AM, Aljoscha Krettek
wrote:
> By the way, I don’t think it’s a bug that addSink() returns the Java
> DataStreamSink. Having a Scala specific ve
By the way, I don’t think it’s a bug that addSink() returns the Java
DataStreamSink. Having a Scala specific version of a DataStreamSink would not
add functionality in this place, just code bloat.
> On 14 Mar 2016, at 10:05, Fabian Hueske wrote:
>
> Yes, we will have more of these issues in the
Yes, we will have more of these issues in the future and each issue will
need a separate discussion.
I don't think that clearly unintended errors (I hope we won't find any
intended errors) are a sufficient reason to break stable a stable API.
IMO, the question that needs to be answered how much of
Hi,
I think this is an important question that will surely come up in some
cases in the future.
I see your point Robert, that we have promised api compatibility for 1.x.y
releases, but I am not sure that this should cover things that are clearly
just unintended errors in the api from our side.
I
On 13.03.2016 12:14, Robert Metzger wrote:
I think its too early to fork off a 2.0 branch. I have absolutely no idea
when a 2.0 release becomes relevant, could be easily a year from now.
at first i was going to agree with Robert, but then...I mean the issue
with not allowing breaking changes
is
This approach means that we will have API breaking changes lingering around
in random people's remote repos that will be untrackable in no time and
people will not be able to build on each others changes. Whoever will have
the pleasure to eventually merge those together will be on the receiving
end
I think its too early to fork off a 2.0 branch. I have absolutely no idea
when a 2.0 release becomes relevant, could be easily a year from now.
The API stability guarantees don't forbid adding new methods. Maybe we can
find a good way to resolve the issue without changing the signature of
existing
Ok, if that is what we promised let's stick to that.
Then would you suggest to open a release-2.0 branch and merge it there?
On Sun, Mar 13, 2016 at 11:43 AM, Robert Metzger
wrote:
> Hey,
> JIRA was down for quite a while yesterday. Sadly, I don't think we can
> merge the change because its API
Hey,
JIRA was down for quite a while yesterday. Sadly, I don't think we can
merge the change because its API breaking.
One of the promises of the 1.0 release is that we are not breaking any APIs
in the 1.x.y series of Flink. We can fix those issues with a 2.x release.
On Sun, Mar 13, 2016 at 5:27
The JIRA issue is FLINK-3610.
On Sat, Mar 12, 2016 at 8:39 PM, Márton Balassi
wrote:
>
> I have just come across a shortcoming of the streaming Scala API: it
> completely lacks the Scala implementation of the DataStreamSink and
> instead the Java version is used. [1]
>
> I would regard this as a
Hey,
I have just come across a shortcoming of the streaming Scala API: it
completely lacks the Scala implementation of the DataStreamSink and instead
the Java version is used. [1]
I would regard this as a bug that needs a fix for 1.0.1. Unfortunately this
is also api-breaking.
Will post it to JI
13 matches
Mail list logo
